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ABSTRACT 


Maritime  data  communications  are  expensive  and  of  limited  capacity.  Currently 
there  is  no  established  infrastructure  to  support  Internet  connectivity  for  sea-going 
vessels.  The  SeaNet  program  is  investigating  maritime  networking  solutions.  One  aspect 
of  the  SeaNet  program  is  promoting  remote  network  management.  Remote  network 
management  will  provide  the  maritime  research  commimity  with  a  flexible  and  cost- 
effective  tool  for  monitoring  sea  based  assets.  The  objective  of  diis  thesis  is  to 
investigate  remote  network  management  over  a  satellite  connection  in  support  of  the 
SeaNet  programs  goals. 

To  research  the  potential  for  remote  network  management,  the  Naval  Postgraduate 
School  has  developed  its  own  SeaNet  laboratory.  This  laboratory  simulates  both  the 
shipboard  and  shore-based  infrastracture  of  the  SeaNet  program  and  conducts  remote 
network  management  on  these  components.  This  thesis  discusses  the  SeaNet  program, 
network  management  concepts,  the  NPS  SeaNet  laboratory,  research  findings  and 
recommendations  for  future  research.  Remote  Network  Management  of  the  SeaNet 
Control  Node  system  is  possible,  however,  continued  research  in  this  area  is  needed. 
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I.  INTRODUCTION 


A.  OVERVIEW 

This  thesis  explores  the  potential  for  network  management  of  shipboard  computer 
resomces  from  a  shore-based  site  utilizing  a  satellite  link.  This  project  is  undertaken  in 
support  of  the  SeaNet  program’s  initiative  of  extending  the  Internet  to  sea-based 
resources.  Specifically,  this  thesis  involves  the  constmction  of  a  laboratory  simulating 
both  the  shipboard  and  shore  based  components  of  the  SeaNet  infrastructure.  This 
infrastructure  is  then  monitored  via  a  commercial  network  management  tool.  Finally  this 
thesis  discusses  findings  and  makes  suggestions  for  continuing  research. 

B.  MOTIVATION 

The  rapid  expansion  of  the  Internet,  coupled  with  advances  in  network 
technology,  is  transforming  the  maritime  research  community.  While  at  sea,  researchers 
are  less  isolated  from  shore-based  computer  resources  since  ship-to-shore  network  access 
is  possible.  Unfortunately,  there  is  no  consolidated  ship-to-shore  networking 
infi^structure  available  to  support  the  maritime  community.  Typical  maritime 
networking  efforts  are  independent,  isolated  and  of  limited  functionality.  Furthermore, 
maritime  communications  involve  expensive  satellite  links  with  relatively  low-bandwidth 
capacities. 

Network  management  is  another  problematic  area  for  the  maritime  community. 
Ideally,  network  management  allows  centralized  management  of  computer  network 
resources.  Ships  typically  are  limited  to  two  options  when  addressing  network 
management.  The  first  possibility  is  for  ship  and  research  persoimel  to  manage  the 
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network  themselves  as  a  collateral  duty.  While  this  may  save  money,  most  personnel  will 
not  possess  the  requisite  knowledge  to  deal  effectively  with  network  problems.  Also,  this 
method  distracts  individuals  from  their  primary  duties.  The  second  alternative  is  that  the 
ship  can  embark  dedicated  network  management  personnel  and  tools,  effectively 
displacing  other  researchers.  This  method  is  both  expensive  and  inefficient.  Most 
network  management  tools  have  the  capacity  to  manage  much  more  than  just  a  shipboard 
local-area  network  (LAN). 

In  order  to  develop  technical  solutions  for  the  problems  associated  with  maritime 
networking,  the  Office  of  Naval  Research  (ONR)  has  sponsored  the  SeaNet  program. 

This  program  is  expected  to  extend  the  Internet  to  the  sea  by  establishing  the  support 
infrastructure  that  the  maritime  community  is  currently  lacking.  SeaNet  will  establish  a 
shore-based  operations  center,  provide  satellite  communications,  develop  shipboard 
communications  servers,  and  support  the  integration  of  new  technologies  [Ref  1]. 

C.  THESIS  OBJECTIVE 

In  support  of  SeaNet’s  objectives,  this  thesis  examines  the  feasibiUty  of  remotely 
monitoring  shipboard  computers.  Remote  network  monitoring  is  expected  to  relieve  the 
ship  of  a  large  number  of  network  administration  fimctions.  Remote  network  monitoring 
is  cost-effective,  allowing  one  individual  to  monitor  many  ships  from  a  shore-based  site. 
The  ship  will  no  longer  need  to  support  an  individual  simply  for  the  sake  of  network 
administration.  Bunk  and  provision  space  can  be  allocated  to  indmduals  more  closely 
aligned  to  the  ship’s  primary  missions. 
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D.  SCOPE  AND  METHODOLOGY 

This  study  focuses  on  the  feasibility  of  conducting  network  management  of  a 

maritime  unit  from  a  shore-based  station.  Specifically  the  study  tests  the  ability  of  the 
shore-based  management  system  to  evaluate  remote  network  status.  It  involves  the 
establishment  of  a  lab  consisting  of  a  shipboard  node  and  a  shore-based  management 
station  connecting  over  a  low-bandwidth  satellite  connection. 

The  Naval  Postgraduate  School  (NPS)  SeaNet  laboratory  is  supported  by  multiple 
partners.  Satellite  data  connectivity  and  commxmication  equipment  is  provided  by  the 
AmericMi  Mobile  Satellite  Corporation  (AMSC).  The  network  management  station  is 
provided  by  the  Space  and  Naval  Warfare  Systems  Command  (SPAWAR),formerly 
known  as  Navy  Research  and  Development  (NRaD):  Research,  Testing,  Development, 
and  Evaluation  (RTDE).  SeaNet  Commxmication  Node  software  is  provided  by  Woods 
Hole  Oceanographic  Institution.  The  simulated  shipboard  nodes  are  provided  by  the 
NPS. 
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E.  THESIS  ORGANIZATION 

Chapter  n  provides  an  insight  into  the  SeaNet  program  and  its  efforts  to  extend 
Internet  capabilities  to  sea-based  units.  Chapter  m  discusses  the  general  concepts  of 
network  management.  Specifically,  it  examines  the  Simple  Network  Management 
Protocol  (SNMP).  Chapter  IV  is  a  description  of  the  NPS  SeaNet  laboratory.  This 
chapter  includes  specifics  on  the  components  and  configurations  used  in  the  laboratory. 
Chapter  V  reports  research  findings.  It  discusses  the  ability  of  the  NPS  network 
management  tool  to  monitor  a  remote  shipboard  station.  Chapter  VI  is  the  conclusion.  It 
recommends  topics  for  future  research  in  the  area  of  network  management. 
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n.  OVERVIEW  OF  THE  SEANET  PROGRAM 


A.  INTRODUCTION 

This  chapter  looks  at  the  SeaNet  program.  It  begins  with  a  brief  history  of 
SeaNet.  Next,  it  describes  the  goals  of  SeaNet.  Third,  it  lists  the  organizations  that  are 
partners  in  the  SeaNet  program  and  discusses  the  SeaNet  Advisory  Panel  that  guides  the 
decision  making  process.  Finally,  it  describes  the  role  of  NPS  as  a  SeaNet  partner. 

B.  BACKGROUND 

SeaNet  is  working  to  create  a  shore-based  and  ship-board 
infrastructure  capable  of  supporting  both  high  and  low  speed  access  to  the 
Internet  from  ships  at  sea.  [Ref  1]. 

SeaNet  originated  in  1995  as  a  collaborative  effort  between  Woods  Hole 
Oceanographic  Institution  (WHOI),  Lamont-Dougherty  Earth  Observatory  (LDEO),  and 
the  Joint  Oceanographic  Institute  (JOI)  with  funding  provided  by  the  National  Science 
Foundation  (NSF).  This  joint  effort  sought  to  develop  a  cost-effective  means  for  sea¬ 
going  vessels  to  access  the  Internet  using  an  INMARSAT  B  communication  system. 

This  initial  effort  led  to  an  expansion  in  the  SeaNet  group’s  role.  In  1997,  the 
National  Oceanographic  Partnership  Program  (NOPP)  of  the  Office  of  Naval  Research 
(ONR)  provided  funding  for  a  new  SeaNet  initiative.  The  new  proposal,  “SeaNet: 
Extending  the  Internet  to  the  Oceanographic  Fleet”  involved  a  $1,478  million  dollar 
investment  over  two  years.  This  program  will  allow  SeaNet  to  evaluate  both  high  and 
low  data-rate  communication  alternatives  that  will  provide  Internet  connectivity  to 
SeaNet  vessels  [Ref  1]. 
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C.  GOALS 

The  SeaNet  program  looks  to  extend  the  Intemet-to-sea  by  establishing  a  shore- 
based  operations  center  with  Internet  Service  Provider  (ISP)  functionality,  providing 
satellite  communications  to  maritime  imits,  developing  shipboard  communications 
servers,  and  supporting  the  integration  of  emerging  technologies  [Ref.  1],  While  initially 
established  to  support  University-National  Oceanographic  Laboratory  System  (UNOLS) 
research  vessels,  it  is  desired  that  this  program  viill  ultimately  mature  into  a  commercial 
entity  capable  of  supporting  any  maritime  imit.  Once  the  maritime  network  service  is 
fully  established,  it  will  be  relatively  simple  to  add  additional  nodes  (ships)  to  the 
network.  Just  as  the  Department  of  Defense’s  Advanced  Research  Projects  Agency 
Network  (ARPANET)  evolved  into  today’s  Internet,  it  is  envisioned  that  eventually  the 
SeaNet  program  will  develop  into  an  ISP  for  maritime  units.  Goal  capabilities  that 
SeaNet  is  intended  to  support  include  network  management,  real  time  data  acquisition, 
remote  control  applications,  client-server  database  queries,  and  file  transfer. 

D.  PARTNERS 

There  are  multiple  organizations  that  have  joined  efforts  in  the  SeaNet  program. 
The  following  is  a  list  of  organizations  and  individuals  from  those  organizations  that 
represent  SeaNet  [Ref.  1]. 
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Joint  Oceanographic  Institutions 
Dr.  Ellen  Kappel 

Liaison/coordination  with  federal  agencies,  scientific  conununity,  and  SeaNet  Advisory 
Panel. 

http://www,joi-odp.org/ _ 

Woods  Hole  Oceanographic  Institution 
Mr.  Andrew  Maffei 

Project  coordination;  SeaNet  Communications  Node  (SCN)  software 
development. 

http://www.whoi.edu/ _ 

Lamont-Doherty  Earth  Observatory 
Mr.  Dale  Chayes 

INMARSAT-B  procurement;  Shipboard  systems  installation  and  testing 

http://www.ldeo.columbia.edu/ _ 

Omnet,  Inc. 

Mr.  Robert  Heinmiller  and  Ms.  Susan  Kubany 

SeaNet  operations  center;  Billing;  Value-added  services _ 

Naval  Postgraduate  School 
Mr.  Rex  Buddenberg, 

Shipboard  implementation  laboratory;  Emerging  technology  planning;  NRaD 
and  Navy  liaison. 

http://www.nps.navy.mil/ _ _ _ 

Naval  Command,  Control  and  Ocean  Surveillance  (NCCOSC):  Navy  Research  and 
Development  Division  (NRaD) 

Technology  transfer  through  NPS _ 

Naval  Oceanographic  Office  (NAVOCEANO) 

Technical  support  persoimel. _ _ 

Table  2.1  SeaNet  Partners 
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E.  THE  SEANET  ADVISORY  PANEL 

To  enhance  decision  making  and  provide  strategic  guidance  for  the  SeaNet 

program,  the  Joint  Oceanographic  Institutions  organization  has  developed  a  SeaNet 

Advisory  Panel  (SAP)  [Ref.  1].  This  panel  is  made  up  of  member  organization 

representatives  and  is  responsible  for  providing  the  following  guidance: 

Review  and  recommend  SeaNet  unit  installations  on  oceanographic  research 
vessels,  and  coordinate  their  usage. 

-  Recommend  priorities  for  further  development  for  SeaNet. 

-  Ensure  coordination  among  scientists,  ship  operators,  funding  agencies  and 
SeaNet. 

Establish  guidelines  to  evaluate  requests  for  SeaNet  equipment  and  services 
by  individual  science  projects. 

F.  THE  ROLE  OF  NPS 

The  primary  role  of  NPS  as  a  member  of  the  SeaNet  program  is  to  perform 
network  research  and  evaluate  emerging  technologies  for  their  potential  benefits  to 
SeaNet.  This  particular  project  evaluates  the  potential  for  network  management  of 
SeaNet  shipboard  resources  from  a  land-based  site.  It  is  critical  that  network 
management  is  considered  an  integral  part  of  the  SeaNet  expansion  so  that  future 
functionality  needs  can  be  considered  today. 

G.  SUMMARY 

SeaNet  is  a  program  funded  by  the  National  Oceanographic  Partnership  Program 
(NOPP)  of  the  Office  of  Naval  Research  (ONR)  to  provide  computer  networking 
resources  and  Internet  access  to  vessels  at  sea.  This  program  has  partner  organizations 
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that  are  working  together  to  create  an  infrastructure  for  researching  these  goals.  As  a 
partner  NPS  is  conducting  research  on  innovative  technologies  that  will  support  SeaNet. 
This  thesis  addresses  remote  network  management  of  SeaNet  resources. 
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m.  NETWORK  MANAGEMENT 


A.  INTRODUCTION 

This  chapter  will  discuss  the  concept  of  network  management.  First,  it  will 
present  a  background  for  network  management  and  define  terms.  Second,  it  will  discuss 
the  Simple  Network  Management  Protocol  (SNMP)  and  the  Remote  Network 
Management  (RMON)  extension  to  SNMP.  Third,  this  chapter  will  discuss  the 
Management  Information  Base  and,  finally,  the  imderlying  protocols  of  SNMP:  Internet 
Protocol  (IP)  and  User  Datagram  Protocol  (UDP). 

B.  BACKGROUND 

Network  management  is  a  means  of  collecting  information.  Network 
management  software  monitors  the  health  and  viability  of  network  devices  such  as  hosts, 
servers,  and  routers.  By  monitoring  the  health  of  each  component,  network  management 
tools  ensure  the  well-being  of  the  network  as  a  whole.  Ideally,  network  management  is 
simple,  reliable,  secure,  efficient  and  inexpensive.  The  best  network  management  tools 
are  imobtrusive  while  remaining  accessible  to  the  network  user.  Reporting  status  changes 
and  detecting  network  problems  is  a  crucial  prerequisite  for  reliable  service. 
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Network  management  typically  occurs  through  a  series  of  request^response 
messages.  A  Network  Management  Station  (NMS)  monitors  one  or  many  network 
devices.  The  network  devices  run  applications  known  as  agents.  The  NMS  sends 
requests  for  information  to  the  agents  on  a  regular  cycle.  The  agents  in  turn  supply  the 
NMS  with  appropriate  responses.  An  agent  may  also  initiate  communications  with  the 
NMS  when  a  pre-defined  condition  is  met.  These  devices  and  processes  are  discussed  in 
more  detail  in  the  following  sections. 

C.  TERMS 

TTie  model  for  network  management  includes  the  following  key  elements: 
network  management  station  (NMS),  agents,  management  information  base  (MIB),  and 
network  management  protocol. 

1.  Network  Management  Station  (NMS) 

The  NMS  is  a  central  monitoring  host  for  the  network  management  system.  It 
collects,  processes  and  displays  information  about  the  network.  The  NMS  maintains  a 
one-to-many  relationship  between  itself  and  a  set  of  managed  network  devices.  The  NMS 
is  able  to  get  and  set  variables  in  the  managed  devices,  and  can  also  receive  messages  from 
the  agents.  It  is  possible  to  have  several  NMS  hosts,  each  of  which  can  manage  all  (or  a 
subset)  of  the  stations  in  the  configuration. 
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An  NMS  has  the  following  components: 

a  set  of  management  applications  for  data  analysis  and  fault  recovery. 

-  an  interface  by  which  the  network  NMS  may  monitor  and  manage  the 
network. 

-  the  capability  of  actively  conducting  monitoring  and  control  of  remote 
elements  in  the  network. 

-  a  database  of  information  extracted  from  the  managed  entities  in  the  network. 

The  specific  NMS  software  used  in  this  thesis  project  is  the  HP  OpenView 

program  running  on  a  Hewlett-Packard  Apollo  Series  700  computer.  More  information 
on  this  system  is  provided  in  Chapter  IV. 

2.  Agent 

Agent  software  runs  on  network  devices,  allowing  them  to  be  managed  by  the 
NMS.  Agents  respond  to  get  and  set  messages  sent  by  the  NMS  and  notify  the  NMS  if 
any  predefined  conditions  are  met.  Network  devices  which  include  running  agents  may 
be  physical  (such  as  a  host,  router,  or  bridge)  or  logical  (such  as  a  network  service  or 
application  program). 

Although  a  network  typically  contains  many  agents,  this  thesis  project  looks  only 
at  managing  one  network  device,  a  personal  computer  (PC).  The  PC  runs  a  Simple 
Network  Management  Protocol  (SNMP)  agent  under  the  Red  Hat  Linux  operating 
system,  version  5.0. 

3.  Management  Information  Base  (MIB) 

The  MIB  is  a  database  of  network  and  network  device  information.  Network 
devices  are  managed  by  representing  each  device  as  a  set  of  objects.  Each  object  is 
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essentially  a  data  variable  that  represents  one  aspect  of  the  managed  device.  The 
collection  of  these  objects  is  simply  a  database  that  is  referred  to  as  a  MIB.  Maintaining 
the  MB  is  the  responsibility  of  the  NMS.  MB  objects  are  divided  into  classes,  allowing 
certain  classes  to  be  applied  to  different  network  devices.  MB-II,  the  current  MB 
standard,  is  discussed  in  depth  in  section  E  of  this  chapter. 

4.  Network  Management  Protocol 

The  network  management  station  and  network  agents  are  linked  by  a  network 
management  protocol.  This  protocol  defines  the  structure  of  information  transferred  over 
the  network.  The  protocol  most  often  used  for  the  management  of  Transmission  Control 
Protocol/Intemet  Protocol  (TCP/P)  networks  is  the  Simple  Network  Management 
Protocol  (SNMP). 

D.  SIMPLE  NETWORK  MANAGEMENT  PROTOCOL 

This  section  discusses  the  Simple  Network  Management  Protocol  (SNMP) 
versions  1, 2  and  3. 

1.  Overview 

The  leading  solution  for  network  management  is  the  Simple  Network 
Management  Protocol  (SNMP).  “The  SNMP  protocol  defines  exactly  how  a  manager 
communicates  with  an  agent”  [Ref.  2].  Outlined  in  Request  for  Comment  (RFC)  1157, 
SNMP  version  I  was  adapted  as  the  standard  for  TCP/IP-based  Internets  in  1989.  SNMP 
is  a  simple,  inexpensive  and  mature  network  management  protocol  with  an  extensive 
support  base. 
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SNMP  operates  at  the  application  layers  of  both  the  Open  Systems 
Interconnection  (OSI)  and  Internet  Protocol  (IP)  models  for  networking.  Figure  3.1 
depicts  the  OSI  networking  model  while  Figure  3.2  depicts  the  correspondence  between 
the  OSI  model  and  the  widely  implemented  IP  model.  Like  all  application  layer  software, 
SNMP  transports  data  over  the  network  using  conventional  transport  protocols. 
Unfortunately,  data  loss  failures  due  to  a  variety  of  causes  can  prevent  packets  from 
traveling  to  or  from  a  host  application  layer.  This  means  that  network  management  may 
be  lost  when  it  is  most  needed,  (i.e.  when  some  part  of  the  network  fails).  In  practice, 
however,  using  an  application  level  protocol  for  network  management  works  well  for  two 
reasons.  First,  in  the  case  of  hardware  failiue,  the  level  of  the  protocol  does  not  matter  - 
the  NMS  can  communicate  with  those  devices  that  remain  operating  and  use  success  (or 
failure)  to  help  locate  the  problem.  Second,  using  conventional  transport  protocols  means 
the  NMS’s  packets  will  be  subject  to  the  same  conditions  as  normal  traffic.  Thus,  if 
delays  are  high,  a  NMS  will  find  out  immediately  [Ref  2]. 
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Layer  Name 

Number 

Description 

Application 

7 

Specifies  how  application  program  uses  the  network:  SNMP 

Presentation 

6 

Method  used  to  represent  data:  ASN.l 

Session 

5 

Method  used  to  establish  a  communication  Session 

Transport 

4 

Method  used  to  ensure  reliability  of  delivery 

Network 

3 

Method  used  to  direct  data 

Data  Link 

2 

Access  method  that  hardware  uses  to  run  on  physical  media 

Physical 

1 

Actual  hardware  used  to  connect  network  devices 

Figure  3.1  The  OSI  Model  for  Networking 
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Figure  3.2  Correspondence  between  OSI  and  IP  protocol  layer  models,  and  objects  passed 

between  corresponding  host  layers.  [Ref.  3] 
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2. 


SNMP  Protocol  Data  Unit 


The  SNMP  message,  known  as  a  Protocol  Data  Unit  (PDU),  is  used  to  exchange 
information  between  the  NMS  and  the  agents.  There  are  five  types  of  PDUs: 
GetRequest,  GetNextRequest,  SetRequest,  GetResponse  and  Trap .  The 
structure  of  the  generic  PDU  is  shown  in  Figure  3.3. 
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Message  Tag 


Message  Length 


SNMP  Message  Value 


Version 

Community  Name 

PDU  Field  Value 

Indicates  SNMP  Version 

Authenticated  against 

Must  be  one  of  the  5 

community  list  held  by  agent 

supported  data  types 

_ 

PDU  Field  Value 


PDUTag 

Either  GetRequest,  GetNextRequest, 
GetResponse,  SetRequest,  or  Trap 


PDU  Length 


Request  ID  Error  Status  Error  Index 

Number  assigned  to  the  request  used  only  by  Used  only  by 
sent  from  the  NMS  to  the  agent  Ge  tResponse  GetResponse 


Variable  Binding  List 
List  of  intances  of  the  managed  objects  that 
are  operated  on  by  the  message  *s  command 


Variable  Binding  List  Tag 


Variable  Binding  List  Length 


Variable  Binding  List  Value 


Variable  1  Tag  Variable  2  Tag  Variable  3  Tag  Variable  4  Tag  Variable  5  Tag  . . .  Variable  n-1  Tag  Variable  n  Tag 


Object  ID  Field 

Value  Field 

Managed  Object ’s 

Actual  Value 

Identification 

of  the  Object 

Figure  3.3  The  generic  Simple  Network  Management  Protocol  (SNMP)  Data  Unit  (PDU) 
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a.  The  GetRequest  PDU 

The  NMS  issues  the  GetRequest  PDU  to  get  MIB  values  from  an 
agent.  The  receiving  SNMP  agent’s  response  to  a  GetRequest  PDU  is  a 
GetResponse  PDU  containing  the  same  request-id  and  the  pertinent  data.  The 
GetRequest  operation  is  atomic,  meaning  that  either  all  of  the  values  are  retrieved  or 
none  are.  If  the  responding  agent  is  able  to  provide  values  for  all  of  the  variables  listed  in 
the  incoming  variable  bindings  list,  then  the  GetResponse  PDU  includes  the  variable- 
bindings  field,  with  a  value  supplied  for  each  variable.  If  any  one  the  variable  values 
cannot  be  supplied,  then  no  values  are  returned  and  an  error  code  is  generated. 

The  request  and  response  behavior  of  SNMP  PDUs  is  shown  in  Figure  3.4. 

GetRequest 


Time 

rk  Management 
Station 

GetNextRequest 

SetRequest 

Agent 

rk  Management 
Station 

Trap 

A'''' 

Agent 

o 

i 

4r'' Get  Response 

u 

:z; 

Figure  3.4  SNMP  PDU  request  and  response  behavior,  requested  and  trapped. 

b.  The  GetNextRequest  PDU 

Almost  identical  in  structure  to  the  GetRequest  PDU  is  the 
GetNextRequest  PDU.  In  the  GetNextRequest  PDU,  for  each  variable,  the  agent 
returns  the  value  of  the  object  instance  that  is  next  in  lexicographical  order  (not  just  the 
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next  object).  This  allows  the  NMS  to  retrieve  information  from  an  agent  without 
knowing  exactly  which  MIB  objects  the  agent  supports.  It  also  provides  an  efficient 
mechanism  for  searching  a  table  whose  entries  are  unknown.  Note  that 
GetNextRequest  only  looks  for  the  next  object  instance  that  occurs  lexicographically 
after  the  identifier  supplied.  There  is  no  requirement  that  the  supplied  identifier  represent 
an  actual  object.  Like  GetRequest,  GetNextRequest  is  atomic.  Also  like 
GetRequest,  improper  requests  will  generate  GetResponse  error  codes. 

c.  The  SetRequest  PDU 

The  SetRequest  PDU  is  used  by  the  NMS  to  change  the  value  of  a 
MIB  variable  at  the  agent.  The  agent  responds  to  the  SetRequest  PDU  with  a 
GetResponse  PDU  that  reflects  the  updated  information.  As  before,  the 
SetRequest  operation  is  atomic,  meaning  that  either  all  of  the  variables  are  updated  or 
none  is.  Bad  requests  will  result  in  GetResponse  error  messages  from  the  agent. 

A  major  flaw  of  SNMP  is  that  it  provides  no  means  of  security. 

Specifically,  there  is  no  capability  to  authenticate  the  source  of  a  management  message 
nor  any  capability  to  prevent  eavesdropping”  [Ref  4].  Although  an  SNMP  message  must 
contain  a  valid  community  name,  this  name  may  be  learned  by  anyone  who  intercepts  an 
SNMP  message.  SNMP  is  extremely  vulnerable  to  attacks  that  modify  network  device 
configurations  using  the  SetRequest  PDU.  For  this  reason,  many  vendors  choose  not 
to  employ  the  SetRequest  PDU  in  their  implementations. 
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d.  The  GetResponse  PDU 

The  GetResponse  PDU  is  used  only  as  a  response  to  GetReques  t 
and  GetNextRequest  queries.  If  the  agent  is  able  to  find  values  for  all  instances 
requested  in  the  Get  PDU  it  will  generate  a  GetResponse  PDU  with  the  appropriate 
values.  The  GetResponse  PDU  looks  exactly  the  same  as  the  originating  Get  PDU  except 
that  the  PDU  tag  indicates  a  GetResponse  PDU  and  the  Value  Field  will  have  actual 
values. 


If  the  agent  is  unable  to  process  the  Get  PDU  for  any  reason,  it  will  return 
an  error  code.  Since  the  GetResponse  PDU  is  atomic  it  cannot  process  some  values  while 
providing  error  codes  for  others.  Any  single  error  will  result  in  an  overall  error  code. 

The  following  error  conditions  are  possible: 

-  noSuchName:  An  object  named  in  the  variable  bindings  field  does  not  match 
any  object  identifier  in  the  relevant  MIB  view. 

-  tooBig:  responding  size  of  the  resulting  GetResponse  PDU  exceeds  local 
limitations. 

-  genErr :  Responding  entity  is  not  able  to  supply  a  value  for  at  least  one  of  the 
object  for  some  reason. 

-  badValue:  badValue  is  used  only  in  response  to  the  SetRequest  PDU. 
badValue  is  returned  if  the  SetRequest  PDU  contains  at  least  one 
pairing  of  variable  name  and  value  that  is  inconsistent.  The  inconsistency 
might  be  in  the  type,  length,  or  actual  value  of  the  supplied  value 

e.  TheTrapPDU 

The  Trap  PDU  is  used  by  the  agent  to  send  unsolicited  MIB  values  to  the 
NMS.  Traps  occur  when  MIB  values  that  are  being  monitored  by  the  agent  exceed  a 
preset  threshold.  Each  station  is  responsible  for  notifying  the  management  station  of  any 
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unusual  event;  for  example,  the  agent  crashes  and  is  rebooted,  a  link  fails,  or  an  overload 
condition  as  defined  by  the  packet  load  crosses  some  threshold. 

Once  a  management  station  is  alerted  to  an  exception  condition,  it  may 
choose  to  take  some  action.  At  this  point,  the  management  station  may  direct  polls  to  the 
agent  reporting  the  event  and  perhaps  to  some  nearby  agents  in  order  to  diagnose  any 
problem  and  to  gain  more  specific  information  about  the  exception  condition. 

Trap  directed  polling  can  result  in  substantial  savings  of  network  capacity 
and  agent  processing  time.  In  essence,  the  network  is  not  made  to  carry  management 
information  that  the  management  station  does  not  need,  and  agents  are  not  made  to 
respond  to  frequent  requests  for  xminteresting  information. 

The  PDU  Field  Value  for  a  trap  differs  from  that  of  the  generic  PDU.  The 
trap  structure  is  shown  in  Figure  3.5 
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generated 

Bindings  List 

Figure  3.5  The  Trap  PDU 
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3. 


SNMP  Version  2 


SNMPv2  was  adapted  as  an  upgrade  to  SNMP  in  1993  (later  revised  in  1996) 
[Ref.  4].  SNMPv2  enhances  SNMP  in  three  specific  areas:  the  structure  of  management 
information,  manager-to-manager  communications,  and  protocol  operations.  SNMPv2 
adds  several  new  data  types  and  enhances  documentation  associated  with  MIB  objects. 
The  SNMPv2  MIB  contains  information  about  the  operation  of  SNMPv2  itself  and 
information  about  the  configuration  of  a  SNMPv2  NMS  or  agent.  While  the  1993 
version  of  SNMPv2  included  security  enhancements,  these  enhancements  were 
problematic  and  dropped  altogether  in  the  1996  revision. 

SNMPv2  supports  several  additional  transport  protocols  such  as  AppleTalk, 
Internetwork  Packet  Exchange  (IPX),  and  the  Open  Systems  Interconnection  (OSI) 
Connectionless  Network  Protocol  (CLNP)  stacks.  SNMPv2  also  introduces  two  new 
PDUs:  GetBulkRequest  and  InformRequest .  GetBulkRequest  allows  for 
the  collection  of  large  amounts  of  data  without  retrieving  each  data  field  one  at  a  time  as 
the  GetNextRequest  PDU  does  [Ref.  5].  InformRequest  facilitates  NMS-to- 
NMS  communications.  The  manager-to-manager  reporting  capabilities  allow  multiple 
NMS  hosts  to  be  configured  in  a  hierarchical  fashion,  with  several  lower-tier  NMS  hosts 
reporting  to  a  single  higher-tier  NMS. 
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Additionally,  SNMPv2  implements  mechanisms  to  assure  that  multiple  NMS 
communications  are  conducted  properly.  The  SNMPv2  Structure  of  Management 
Information  (SMI)  was  modified  to  accommodate  64-bit  counters  (SNMPvl  uses  32-bit 
counters).  Error  reporting  codes  are  expanded  and  agents  are  allowed  to  process  partial 
requests  for  information. 

Despite  these  improvements,  the  public  reception  of  SNMPv2  has  been  less  than 
positive.  The  initial  security  corrections  (later  dropped)  were  perceived  as  complicated 
and  ineffectual.  Additionally,  agent  configuration  was  difficult  and  the  administration  of 
SNMPv2  was  a  great  deal  more  complex  than  SNMPvl .  In  short,  SNMP  was  no  longer 
simple.  Currently,  SNMPv2  is  rarely  used. 

4.  SNMP  Version  3 

Current  initiatives  are  underway  to  introduce  a  third  version  of  SNMP.  SNMPvS 
will  combine  the  functionality  of  SNMPvl  and  experimental  derivations  of  SNMPv2 
(SNMPv2p,  SNMPv2u  and  SNMPv2*)  [Ref  6].  SNMPvS  is  expected  to  be 
simultaneously  secure,  extendable,  and  easy  to  administer  and  configure.  SNMPvS 
includes  3  modules: 

The  Message  Processing  and  Control  module  handles  SNMP  message  creation 
and  parsing  functions,  and  also  determines  if  proxy  handling  is  required  for 
any  SNMP  message  [Ref  7]. 

-  The  Local  Processing  module  performs  access  control  for  variable  binding 
data,  processing  that  data  and  trap  processing  [Ref.  7]. 

-  The  Security  module  provides  authentication,  and  encryption  functions,  and 
checks  the  timeliness  of  certain  SNMP  messages  [Ref  7]. 
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Currently,  SNMPv3  is  in  Internet  draft  form.  The  SNMPvS  working  group  is 
expected  to  complete  all  core  specifications  and  forward  documents  to  the  Internet 
Engineering  Steering  Group  (lESG)  for  consideration  as  Draft  Standard  RFCs  in  October 
1998  [Ref  8].  Consequently,  all  further  mention  of  SNMP  in  this  thesis  refers  to  SNMP 
version  1. 

E.  THE  MANAGEMENT  INFORMATION  BASE  (MIB) 

1.  Background 

The  MIB  is  the  collection  of  all  the  objects  that  the  NMS  can  manage.  MIB 
objects  are  the  unique  MIB  names  and  MIB  instances  are  the  values  for  those  names.  For 
example,  in  the  key=value  pair  x=4,  x  is  the  object  and  4  is  the  instance.  The  NMS 
collects  specific  instances  for  each  object  and  device,  and  maintains  those  instances  in  a 
database  known  as  the  MIB  database.  The  MIB  database  is  constantly  updated  using 
SNMP.  The  >JMS  issues  MIB  objects  to  the  agents  using  the  Get  commands.  The 
agents  respond  to  the  Get  Commands  with  GetResponse  messages  containing  the 
requested  MIB  instance  or  through  issuing  Trap  messages  (which  contain  MIB  instances). 
Either  way  the  MIB  database  is  populated  with  instance  values. 

The  MIB  is  defined  separately  from  SNMP.  In  other  words,  SNMP  provides  a 
framework  for  transferring  MIB  objects  but  does  not  define  what  the  objects  should  be. 
This  flexible  design  allows  users  to  define  and  implement  their  own  MIB  objects  as 
required.  The  MIB  structure  can  be  thought  of  as  a  hierarchical  organization  chart  (see 
Figure  3.6).  MIB  objects  are  assigned  specific  names  and  places  within  the  chart  to 
ensure  uniqueness  and  prevent  redundancy.  The  MIB  hierarchy  is  divided  into  classes. 
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These  classes  are  structured  according  to  who  is  creating  the  MIBs  and  what  devices  the 
MIBs  are  designed  to  manage. 


Figure  3.6  The  Management  Information  Base  (MB)  Hierarchical  Structure 


Objects  in  a  MB  are  defined  with  the  Abstract  Syntax  Notation 
One  (ASN.  1)  naming  scheme,  which  assigns  each  object  a  long  prefix  that 
guarantees  the  name  will  be  unique.  For  example,  an  integer  that  counts 
the  number  of  IP  datagrams  a  device  has  received  is  named; 
iso.org.dod.intemet.mgmt.mib.ip.ipInReceives  [Ref  2] . 

Fiuthermore,  when  the  object  name  is  represented  in  an  SNMP 
message,  each  part  of  the  name  is  assigned  an  integer.  Thus,  in  an  SNMP 
message,  the  name  of  ipInReceives  is:  1 .3 .6. 1 .2. 1 .4  [Ref  2] . 

It  must  be  noted  that  MB  "objects"  are  simple  variables  and  not  really  objects  at 

all.  A  MB  object  may  be  a  simple  two-dimensional  variable  (indicating  only  MB  object 

name  and  network  device  name),  or  an  array  or  table  (such  as  an  IP  routing  table). 
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This  chapter  will  now  discuss  two  widely  accepted  sets  of  MIB  objects;  MIB-II 
andRMON. 

2.  Mffi-n 

MBB-n  is  generally  accepted  as  the  standard  or  core  MIB.  It  contains  information 
deemed  essential  for  either  fault  or  configuration  management  [Ref  4].  Originally 
defined  in  RFC  1213,  MIB-II  expands  on  a  1988  MIB  known  as  MIB-I.  Originally 
released  in  1990,  MIB-II  was  later  revised  in  1991.  MIB-II  contains  10  groups  and  171 
objects. 

The  MIB-n  object  groups  are  as  follows:  System,  Interfaces,  Address  Translation 
(AT),  Internet  Protocol  (IP),  Internet  Control  Message  Protocol  (ICMP),  Transmission 
Control  Protocol  (TCP),  User  Datagram  Protocol  (UDP),  Exterior  Gateway  Protocol 
(EGP),  Transmission,  Simple  Network  Management  Protocol  (SNMP).  Each  of  these 
object  groups  are  now  examined  in  further  detail. 
a.  The  Systems  Group 

The  Systems  group  contains  descriptive  information  about  a  managed 
device  such  as  point  or  contact  information  (sysContact)  and  the  host's  operating  system 
(sysDescr).  The  Systems  Group  contains  seven  objects. 
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b.  The  Interfaces  Group 

The  Interfaces  group  contains  generic  information  about  the  managed 
device’s  network  interfaces.  This  information  includes  interface  product  name  and 
version  (ifDescr),  the  speed  of  the  interfaces'  current  data  rate  capacity  (ifSpeed),  the 
number  of  octets  transmitted  (ifOutOctets)  and  the  number  of  inbormd  packets  that  were 
discarded  due  to  errors  (iflnErrors).  The  Interfaces  Group  contains  twenty-three  objects. 

c.  The  Address  Translation  (AT)  Group 

The  Address  Translation  (AT)  group  provides  information  on  how  the 
device  maps  a  physical  address  from  a  network  (IP)  address.  When  MIB-II  was  written,  it 
was  decided  that  the  MIB-I  implementation  of  the  AT  group  was  too  limiting  and  that  AT 
information  was  included  in  other  places  in  MIB-II.  Consequently,  the  AT  group  was 
given  a  depreciated  status.  The  AT  group  is  included  in  MIB-II,  however,  to  provide 
compatibility  with  existing  MIB-I  implementations.  The  AT  group  contains  three 
objects. 

d.  The  Internet  Protocol  (IP)  Group 

The  Internet  Protocol  (EP)  group  provides  information  on  DP  operations. 
These  operations  include  the  total  number  of  input  datagrams  successfully  delivered  to  IP 
user  protocols  (ipInDelivers),  the  Subnet  mask  associated  with  the  IP  address  of  the 
managed  device  (ipAdEntNetMask),  and  the  IP  address  of  the  next  hop  for  a  given  route 
(ipRouteNextHop).  The  IP  group  contains  forty-eight  objects. 
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e.  The  Internet  Control  Message  Protocol  (ICMP)  Group 

The  Internet  Control  Message  Protoeol  (ICMP)  group  contains  statistics  on 
ICMP  input  and  output  operations.  These  statistics  include  the  total  number  of  ICMP 
messages  received  (icmpInMsgs),  the  Number  of  ICMP  Echo  Reply  messages  received 
(icmpInEchoReps),  and  the  niunber  of  ICMP  Address  Mask  Reply  messages  sent 
(icmpOutAddrMaskReps).  The  IP  group  contains  twenty-six  objects. 

f.  The  Transmission  Control  Protocol  (TCP)  Group 

The  Transmission  Control  Protocol  (TCP)  group  contains  statistics  about 
TCP  operations.  These  statistics  include  the  device's  TCP  retransmission  algorithm 
(tcpRtoAlgorithm),  the  total  nmnber  of  retransmitted  segments  (tcpRetranSegs),  and  the 
total  number  of  TCP  segments  received  in  error  (tcpInErrors).  The  TCP  group  contains 
twenty-one  objects. 

g.  The  User  Datagram  Protocol  (UDP)  Group 

The  User  Datagram  Protocol  (UDP)  group  contains  information  relevant 
to  the  UDP  operations.  This  information  includes  the  total  number  of  UDP  packets 
delivered  (udpInDatagrams)  and  the  total  number  of  UDP  datagrams  received  which  had 
no  application  at  the  desired  port  (udpNoPorts).  The  UDP  group  contains  eight  objects. 

h.  The  Exterior  Gateway  Protocol  (EGP)  Group 

The  Exterior  Gateway  Protocol  (EGP)  group  contains  information 
concerning  the  operation  of  EGP.  The  EGP  group  includes  eight  objects  which  comprise 
the  EGP  Neighbor  Table,  providing  information  about  each  of  the  neighbor  gateways 
known  to  the  device.  The  EGP  group  contains  twenty  objects. 
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u  The  Transmission  Group 

The  Transmission  group,  also  known  as  the  dot3  group,  contains 
information  about  the  transmission  schemes  and  access  protocols  at  each  system  interface 
[Ref  4],  Based  on  the  transmission  media  underlying  each  interface  on  a  system,  the 
corresponding  portion  of  the  Transmission  group  is  mandatory  for  that  system.  When 
Internet-standard  definitions  for  managing  transmission  media  are  defined,  the 
Transmission  group  is  used  to  provide  a  prefix  for  the  names  of  those  objects  [Ref  9]. 
The  sixteen  Transmission  MBs  are  currently  defined.  These  groups  include  X.25  packet 
technolo^,  Token  Ring,  Frame  Relay,  and  Fiber  Distributed  Data  Interface  (FDDI) 
technology  among  others. 

j.  The  SNMP  Group 

The  SNMP  group  contains  information  about  SNMP  operations.  This 
information  includes  the  total  number  of  messages  delivered  to  the  agent  from  the 
transport  service  (snmpInPkts)  and  the  total  number  of  SNMP  SetRequest  PDU's 
accepted  and  processed  by  the  agent  (snmpInSetRequests).  There  are  twenty-eight 
objects  in  the  SNMP  group. 

3.  Remote  Network  Management 

First  issued  in  1991,  Remote  Network  Management  (RMON)  acts  as  a  supplement 
to  MB-n.  RMON  extends  SNMP’s  capabilities  to  include  the  management  of  local-area 
networks  (LANs).  RMON  agents  collect  statistics  about  the  network  itself,  not  just  the 
network  devices.  “Without  RMON  an  NMS  has  difficulty  constructing  a  profile  of  the 
network  activity”  [Ref  10]. 
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Since  RMON  monitors  the  network  rather  than  the  device,  only  one  RMON  agent 
(called  an  RMON  probe)  is  required  for  the  network.  Thus,  a  LAN  consisting  of  many 
SNMP  agents  may  contain  only  one  RMON  probe. 

RPC  1757,  Remote  Network  Monitoring  Management  Information  Base,  lists  five 
primary  goals  that  can  be  realized  with  RMON  implementation  [Ref  10]: 

-  Off-line  operation:  allowing  the  RMON  agent  to  collect  data  even  if  the 
connection  between  it  and  the  NMS  is  interrupted  (This  RMON 
implementation  goal  will  be  of  particular  interest  to  future  research  projects). 
Off-line  operation  allows  the  RMON  probe  to  continue  to  collect  information 
on  the  local-area  network  (LAN)  even  while  it  is  disconnected  fi’om  the  NMS. 
This  collected  information  is  then  passed  to  the  NMS  when  connection  occurs. 

-  Preemptive  monitoring:  allowing  the  agent  to  preempt  its  normal  monitoring 
tasks  to  notify  the  NMS  of  a  failure. 

-  Problem  detection  and  reporting:  agent  can  detect  and  report  specific  error 
conditions. 

-  Value-added  data:  Agent  can  collect  and  retrieve  management  data  for  the 
NMS. 

-  Multiple  managers:  agent  must  support  concurrent  communications  with 
multiple  NMS. 

In  1996,  RMON’s  capabilities  were  extended  with  a  version  known  as  RMON-II. 
RMON-II  does  not  replace  RMON-I  but  rather  complements  it.  Together  the  two  RMON 
versions  can  monitor  each  of  the  network  layers.  While  RMON-I  concentrates  on 
monitoring  the  bottom  (physical  and  network)  layers  of  the  IP  stack,  RMON-II  focuses  on 
the  transport  and  application  layers. 
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F.  THE  UNDERLYING  TRANSPORT  PROTOCOLS 

This  section  will  examine  the  stracture  of  the  Simple  Network  Management 

Protocol  (SNMP)  and  its  underlying  transport  protocols,  the  User  Datagram  Protocol 
(UDP)  and  the  Internet  Protocol  (IP)  (See  Figure  3.7).  This  examination  will  help  to 
explain  the  behavior  of  SNMP. 


Figure  3.7  SNMP’s  Underlying  Protocols  [Ref  2] 

These  three  protocols  (SNMP,  UDP,  and  IP)  correspond  to  the  Application, 
Transport  and  Network  layers  of  the  IP  network  model  (see  Figure  3.8). 
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Figure  3.8  The  relationship  of  SNMP  to  TCP/IP  layers  [Refs.  1 1  and  12] 

1.  Internet  Protocol  (IP) 


The  Internet  Protocol  (TP)  acts  as  the  network  layer  for  SNMP.  IP  is  a 
connectionless  and  unreliable  (i.e.  best-effort)  protocol.  The  IP  datagram  header  contains 
the  data  to  route  and  deliver  a  packet  to  its  destination  address  on  the  internet. 

The  IP  datagram  header  consists  of  fourteen  fields  of  various  lengths.  The 
maximum  size  of  an  IP  datagram  (including  header)  is  1500  bytes.  Larger  datagrams  are 
broken  into  firagments  and  transmitted  separately  across  the  internet.  The  IP  Fragment 
Offset  field  provides  a  means  of  ensuring  the  fiiagmented  packets  are  reassembled  in 
proper  order.  Details  on  IP  version  4  can  be  found  in  RFC  791.  The  IP  datagram  format 
is  shown  in  Figure  3.9. 
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Figure  3.9  The  Intemet  Protocol  (IP)  datagram. 


2.  User  Datagram  Protocol  (UDP) 

User  Datagram  Protocol  (UDP)  typically  acts  as  the  transport  protocol  imderlying 
SNMP.  UDP  is  used  to  deliver  packets  to  a  specific  port  address  at  given  host  computer. 
In  contrast  to  the  more  widely  used  Transport  Control  Protocol  (TCP),  UDP  is  simple  and 
unreliable  (i.e.  best  effort).  UDP  is  mueliable  in  that  it  does  not  transmit  a  “receipt” 
packet  to  the  transmitting  address;  therefore  a  sender  never  knows  if  the  intended 
recipient  actually  received  the  packet  or  not.  In  addition,  UDP  does  not  provide  any  data 
flow  control  mechanism  nor  does  it  deal  with  packet  loss  or  corruption.  “Thus,  UDP 
messages  can  be  lost,  duplicated,  or  arrive  out  of  order”  [Ref.  13].  Despite  these 
drawbacks,  UDP  is  often  utilized,  primarily  for  its  simplicity.  Since  SNMP  does  not 
require  all  the  services  of  TCP,  the  simplified  packet  header  of  UDP  eliminates 
unnecessary  overhead. 

Because  SNMP  is  typically  used  to  administer  reliable,  low-delay  LANs,  users 
may  not  encounter  the  shortcomings  of  UDP.  “Application  programs  that  rely  on  UDP 
work  well  in  local  environment  but  fail  in  dramatic  ways  when  used  in  a  larger  TCP/IP 
Internet.”  [Ref.  13]. 

The  UDP  header  consists  of  four  16-bit  fields.  These  fields  identify  the  source 
and  destination  ports  of  each  packet,  the  message  length,  and  provide  a  checksum.  The 
UDP  Source  Port  and  UDP  Checksum  fields  are  optional.  These  fields  are  shown  in 
Figure  3.10. 
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Figure  3.10  The  UDP  Datagram 


Port  numbers  correspond  to  specific  communications  processes  within  a  host 
node.  Peer  processes  are  able  to  communicate  with  each  other  over  a  data  connection  by 
addressing  their  packets  to  a  specific  port  and  address  combination.  This  port  is 
monitored  at  the  peer  host  process.  IP  addressed  port  161  is  reserved  for  SNMP  network 
monitor  messages  and  port  162  is  reserved  for  SNMP  traps.  Some  port  numbers  are 
reserved  y  the  Internet  Assigned  Numbers  Authority  (lANA),  ensuring  port  addresses  are 
imiquely  assigned  [Ref.  14].  An  example  of  UDP  demultiplexing  to  appropriate  ports  in 
an  addressed  host  is  shown  in  Figure  3.11. 

Another  consideration  for  UDP  is  the  way  it  is  handled  by  firewalls.  Typically, 
firewalls  are  configured  to  not  pass  UDP  packet's.  In  order  to  monitor  devices  through 
firewalls  using  SNMP,  the  firewall  needs  to  be  configured  to  allow  UPD  packets  that 
correspond  to  a  specific  UDP  port  addresses  such  as  161  and  162.  Of  course,  firewalls 
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need  not  be  configured  to  accept  all  SNMP  packets,  but  only  those  that  the  NMS  needs. 
One  possible  vulnerability  fi'om  opening  SNMP  UPD  ports  through  a  firewall  is  that 
SNMP  packets  can  be  used  for  a  denial-of-service  type  attack. 


Figure  3.11  UDP  Demultiplexing  Operations 


G.  SUMMARY 

Network  management  is  a  means  of  monitoring  the  condition  of  the  network. 
Network  management  requires  a  Network  Management  Station,  agents,  a  management 
information  base  (MIB)  and  a  network  management  protocol.  Essential  MTR  objects  are 
defined  in  MIB-II  and  its  supplement,  RMON.  Simple  Network  Management  Protocol 
(SNMP)  version  1  is  the  most  widely  used  network  management  protocol.  SNMP  is 
supported  by  the  underlying  protocols  of  UDP  and  IP. 


37 


38 


IV.  THE  NPS  SEANET  LABORATORY 


A.  INTRODUCTION 

This  chapter  describes  the  NPS  SeaNet  laboratory.  It  introduces  the  equipment  of 
a  typical  SeaNet  vessel  that  the  NPS  SeaNet  laboratory  seeks  to  emulate,  provides 
configuration  information,  and  describes  operation  of  the  laboratory  equipment. 

B.  SEANET  VESSEL  RESOURCES 

Regarding  computer  and  communication  resources,  there  is  no  common 
configuration  for  maritime  vessels.  Exact  configurations  vary  firom  ship  to  ship  and  firom 
mission  to  mission.  One  common  component  for  SeaNet  vessels  does  exist,  however,  the 
SeaNet  Control  Node  System.  This  system  is  the  interface  that  bridges  the  vessel’s  LAN 
to  shore  based  resources.  This  section  discusses  the  resources  of  a  single  research  vessel 
(the  Atlantis)  and  provides  a  description  of  the  SeaNet  Communication  Node  (SCN) 
software. 

1.  Computer  and  Satellite  Communication  Resources 

Table  4.1  provides  an  overview  of  the  computer  and  satellite  resources  typically 
available  on  the  WHOI  vessel  Atlantis: 
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_ Computer  Resources _ 

Main  Hub,  Central  Fibronics  Gigahub  capable  of  100  Mb/s _ 

Servers,  Intel  Pentium  based  IBM  PC’s  running  Red  Hat  Linux  version  4.1 _ 

10  Base  T  Ethernet  cabling  throughout  ship _ 

Nine  separate  collision  domains _ 

TCP/IP  protocol  suite  use  _ 

Class  C  network  IP  address  with  domain  name  “atlantis.whoi.edu” _ 

50  IP  nodes  available _ 

Support  for  multiple  Operating  Systems  i.e.,  WinNT,  MacOS,  Solaris,  Unix,  Linux  (Red 

Hat  distribution) _ _ _ 

_ Satellite  Communication  Resources _ 

INMARSAT  A,  Magnavox  MX  2400, 9.6K  baud  data  transfer  rate _ 

INMARSAT  B  High  Speed  Data  (HSD),  Nera  Saturn,  64K  baud  data  transfer  rate _ 

Table  4.1  Vessel  Atlantis  Computer  and  Satellite  Communication  Resources 


2.  Software  Resources 

The  SeaNet  Commimications  Node  software  is  a  browser  based  program 
developed  by  WHOI  and  designed  to  run  on  the  shipboard  SCN  system.  The  SCN 
software  performs  the  following  functions; 

-  Control  and  configuration  of  communication  links  (i.e.  INMARSAT,  AMSC, 
Cellular). 

Satellite  connection  accoimt  based  cost  information. 

-  Batch  file  transfer  capability. 

-  Web  mirroring. 

-  Software  programming  resources  for  enhanced  future  functionality. 

Figure  4.1  shows  Netscape  Navigator  for  Linux  with  the  SeaNet  Cortunimications 
Node  software  running.  This  section  will  briefly  discuss  two  specific  functions  of  the 
SCN  software:  “Comm  Links”  and  “Accoimting”.  The  figure  shows  the  Netscape 
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Navigator  browser  with  four  separate  frames  (characteristic  of  the  SCN  software).  Each 
frame  contains  information  about  the  different  functions  of  the  SCN  software.  The  main 
menu  is  displayed  in  the  upper-left  frame.  As  links  in  the  main  menu  are  selected  they 
open  the  sub  menus  in  the  remaining  three  frames.  The  “Comm  Links”  are  shown  in  the 
lower  right  frame  and  “accounting”  in  the  upper  right  frame.  The  “Comm  Links”  frame 
displays  the  interfaces  that  are  configured  on  the  host  system  and  their  current  status.  The 
“Accotmting”  frame  provides  information  on  transfer-rates,  costs  and  times  that  the  links 
were  used  based  on  account  information.  The  lower  left  frame  displays  an  expanded 
“Comm  Link”  menu  used  for  configuration  of  specific  interfaces. 
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C.  NPS  SEANET  LABORATORY  EQUIPMENT 

The  NPS  SeaNet  laboratory  is  divided  into  two  sections,  shipboard  and  shore- 
based.  The  shipboard  section  represents  equipment  that  would  normally  be  foimd  on 
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board  a  maritime  vessel.  This  includes  the  KVH  Tracphone  and  an  IBM-compatible 
Personal  Computer  running  the  SeaNet  Communications  Software(SCN)  software.  The 
shore-based  section  includes  a  HP-UNIX  workstation  running  OpenView  and  an  Internet 
Service  Provider  (ISP)  connection.  Typical  communication  is  via  satellite  link. 

Although  the  laboratory’s  division  indicates  a  shipboard  section,  all  equipment  is 
located  at  NPS.  The  shipboard  and  shore-based  sections  are  named  as  to  reflect  their 
effective  functionality.  By  maintaining  all  laboratory  equipment  in  one  area,  researchers 
are  able  to  manipulate  either  side  of  the  laboratory  and  see  the  resulting  effects  on  the 
opposite,  side.  Ultimately,  this  laboratory  is  used  to  test  and  validate  networking  concepts 
before  they  are  actually  deployed  on  ships. 

1.  Shipboard  Equipment 

a.  SeaNet  Communications  Node  (SCN)  System 
The  SeaNet  Communications  Node  (SCN)  System,  also  known  as  the 
shipboard  computer,  is  essentially  a  Personal  Computer  hosting  the  SCN  software.  The 
primary  functions  of  the  NPS  lab’s  shipboard  computer  is  to  commimicate  with  the 
satellite  telephone,  run  the  SCN  software,  and  to  host  an  SNMP  agent.  The  shipboard  PC 
is  configured  with  two  operating  systems,  Linux  and  Microsoft  Windows  95.  Although 
actual  shipboard  computers  use  only  the  Linux  operating  system,  this  laboratory  uses 
Window  95  as  a  comparison  and  setup  tool.  Justification  for  Window  95  is  that  the  KVH 
Tracphone  manual  only  references  Windows  and  Macintosh  data  connections.  Also, 
operator  familiarity  with  Windows  95  allows  researchers  to  evaluate  functions  in 
Windows  95  and  then  execute  them  in  Linux. 
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Specifications  for  the  NPS  shipboard  computer  are  as  follows: 

Model:  Dell  OptiPlex  GXa 

-  Processor:  Intel  Pentium  n  233  MHz  MMXI 

-  RAM:  64  MB  EDO 

-  CDROM:  Toshiba  XM-6202B  ATAPI 32X 

-  Operating  System:  Win95  /  Red  Hat  Linux  5.0 

-  NIC:  3COM  Fast  Etherlink  XL  lO/lOOMb  TX  Ethernet  Adapter 

-  Monitor:  Dell  D1025TM. 

b.  KVH  Tracphone  Mobile  Satellite  Telephone  System 

The  KVH  Tracphone  is  used  to  establish  a  satellite  data  connection 
between  the  shore-based  NMS  and  the  shipboard  PC.  This  equipment  is  provided  by  the 
American  Mobile  Satellite  Corporation  (AMSC)  to  allow  research  and  evaluation  of  their 
satellite  data  circuit.  There  are  three  primary  components  to  the  KVH  Tracphone:  the 
antenna,  the  transceiver  unit  and  the  handset.  The  equipment  is  divided  into  above-deck 
and  below-deck  sections.  The  antenna  is  in  the  above-deck  section  while  the  transceiver 
and  handset  are  in  the  below-deck  section. 

Figure  4.2  shows  a  basic  schematic  for  the  KVH  Tracphone  model  used  in 
the  NPS  SeaNet  lab. 
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ANTENNA  PED^AU  RADOME 


CONTROL,  VOICE,  FAX,  DATA 


RF  SIGNAL.  POWER  &  CONTROL 


Figure  4.2  The  KVH  Tracphone  [Ref.  15] 


The  KVH  Tracphone  is  used  to  establish  a  data  connection  through  the 
American  Mobile  Satellite  Corporation  owned  satellite,  AMSC-1.  This  geosynchronous 
satellite  provides  for  voice  and  data  communications.  Currently  AMSC  supports  a  4800 
bps  digital  data  channel  through  AMSC-1.  As  can  be  seen  from  Figure  4.3,  the  AMSC-1 
satellite  provides  substantial  coverage  for  vessels  operating  in  North  American  coastal 
regions. 
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Figure  4.3  AMSC  Satellite  Coverage  [Ref.  16] 


2.  Shore-Based  Equipment 

a.  HP  OpenView  Workstation 

The  HP  OpenView  system  is  an  extremely  powerful  network  management 
tool  capable  of  effectively  monitoring  a  network  of  several  thousand  nodes.  The  NPS 
SeaNet  laboratory,  however,  utilizes  this  tool  to  manage  only  the  SeaNet 
Conununications  Node  (SCN)  system. 


While  HPOV  represents  an  entire  family  of  products,  the  NFS  SeaNet 
laboratory  utilizes  only  the  HPOV  Network  Node  Manager  (NNM).  NNM  provides  the 
following  capabilities  [Ref.  17]; 

View  the  current  topology  of  your  network  as  automatically  discovered 

-  Easily  diagnose  network  faults  and  performance  problems  conveniently  from 
one  location.  This  includes  customizing  and  automating  the  monitoring  of  the 
ship’s  network  and  the  management  station’s  response  to  events. 

-  Access  network  and  system  configuration  information  for  the  nodes  on  your 
network  without  searching  through  files. 

-  Customize  the  management  station  by  integrating  existing  applications  into 
the  HPOV  windows  menu  bar. 

-  Plan  for  future  networking  needs.  This  includes  collecting  and  storing  MIB 
data  for  trend  analysis. 

The  NPS  laboratory’s  HPOV  system  hardware  is  shown  in  Figure  4.4 
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Figure  4.4  The  NFS  SeaNet  Laboratory’s  HP  OpenView  Network  Management  Station, 
an  HP  Apollo  Series  700  workstation  running  the  HP-UX  10.01  operating  system. 

b.  Internet  Service  Provider 

One  of  the  primary  goals  of  the  SeaNet  program  is  to  establish  an  Internet 
Service  Provider  (ISP)  connection  to  maritime  vessels.  Currently  the  commercial 
company  Omnet,  a  SeaNet  partner,  is  fulfilling  these  requirements  and  expects  to  expand 
their  operation  as  the  number  of  SeaNet  units  increases.  The  primary  ISP  for  the  SeaNet 
lab  is  NPS.  NPS  hosts  approximately  50  28.8  kbps  modems.  This  bank  of  modems  is 
used  for  connections  between  the  shipboard  computer  and  the  NPS  campus. 

One  of  the  major  advantages  of  using  NPS  as  an  ISP  is  that  the  dial-in 
connection  is  contained  within  the  firewalls  of  NPS.  By  containing  all  communications 


within  NPS,  the  agent  and  NMS  are  able  to  exchange  UDP  packets  without  addressing 
firewall  configurations  or  restrictions. 

D.  SETUP  AND  CONFIGURATION 

Modem  and  point-to-point  connection  setup  procedures  for  Windows  95  and 
Linux  are  detailed  in  Appendices  A  and  B  respectively. 

E.  OPERATION 

The  shipboard  PC,  regardless  of  operating  system,  issues  standard  AT  style 
modem  commands  through  a  serial  connection  to  the  KVH  transceiver  unit.  The  KVH 
transceiver  unit,  in  turn,  issues  commands  to  the  antenna.  The  KVH  antennae 
communicates  with  the  AMSC-1  satellite  over  a  specific  line  (e.g.  voice,  2400bps  or 
4800bps).  The  satellite  transmits  to  the  AMSC  downlink  station  in  Reston  ,Virginia  and 
then  completes  the  connection  to  the  shore-based  NMS  via  standard  telephone  land  lines. 

The  shipboard  and  shore-based  segments  of  the  laboratory  together  allow  the 
establishment  of  a  4800  bps  point-to  point  coimection  between  the  HP  workstation  NMS 
and  the  SeaNet  PC  via  the  satellite.  This  connection  can  then  be  monitored  and 
appropriate  network  management  and  other  information  can  be  transferred.  Figure  4.5 
illustrates  a  typical  coimection  using  the  KVH  Tracphone.  The  connection  is  initiated 
from  the  shipboard  side  with  the  SCN  system.  The  initial  modem  commands  come  from 
Windows  95  or  Linux  and  are  sent  to  the  KVH  TU. 
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Figure  4.5  The  NFS  SeaNet  Laboratory,  a  typical  connection  between  the  network 
management  station  and  the  SeaNet  Communication  Node  (SCN)  system. 


The  TU  processes  the  commands  and  initiates  a  call  to  the  ISP  being  dialed.  The 
SCN  system  establishes  a  connection  with  an  ISP  through  the  satellite  using  the  KVH  TU 
as  a  modem.  After  a  connection  is  established  then  the  connection  behaves  like  any  other 
dial-up  connection.  This  allows  for  access  to  the  Internet  at  4800bps.  While  this  is  low- 
bandwidth  compared  with  regular  modem  and  LAN  connections,  it  is  capable  of 
supporting  e-mail  and  other  low  data-rate  functions  such  as  selected  experimental  data 
transfer. 
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F. 


SUMMARY 


The  SeaNet  laboratory  was  developed  to  test  the  potential  for  remote  network 
management  of  shipboard  computers.  The  shipboard  side  of  the  SeaNet  laboratory 
consists  of  a  shipboard  computer  hosting  a  Linux  SNMP  agent  and  a  KVH  Tracphone. 
The  shore-based  side  consist  of  an  HP  workstation  hosing  HPOV’s  NNM.  These  two 
divisions  are  connected  by  dialing  into  the  NPS  modem  bank  using  a  4800  bps  satelUte 
data  connection. 
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V.  EXPERIMENTAL  RESULTS 


A.  INTRODUCTION 

This  chapter  discusses  research  findings.  First,  it  addresses  physical  connection 
issues  (such  as  latency  and  data  rate)  encountered  with  the  AMSC  Tracphone  and  AMSC 
satellite  connection.  Second,  it  addresses  the  ability  of  HP  OpenView  to  manage  the  NPS 
simulated  shipboard  node.  Finally,  it  considers  problems  encountered  in  attempting  to 
manage  a  remote  node  with  a  dynamically  assigned  IP  address. 

B.  AMSC  TRACPHONE  FINDINGS 

This  section  discusses  the  physical  properties  of  the  satellite  connection  including 
the  latency  and  throughput  observed  at  NPS.  A  brief  discussion  about  the  Tracphone’s 
ability  to  switch  between  voice  and  data  communications  is  also  included. 

1.  Latency  and  Throughput 

Latency  was  observed  by  using  the  ping  command  to  ping  the  shipboard 
computer  firom  the  network  management  station.  The  average  latency  observed  was 
approximately  2.2  seconds  over  1000  pings.  No  pings  took  less  than  2.1  seconds  or  more 
than  2.4  seconds. 
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Throughput  of  the  connection  was  measured  by  using  the  File  Transfer  Protocol  to 
transfer  files  between  computers.  Files  were  transferred  to  the  shipboard  computer  from 
either  the  NPS  shore-based  computer  (HP)  or  the  file  server  at  WHOI.  The  shipboard 
computer  is  denoted  by  the  operating  system  it  was  running  at  the  time  of  file  transfer: 
Linux  or  Windows  95.  Two  sources  for  dial-in  connection  were  used:  NPS  and  Redshift 
(http://www.redshift.com)  ,  a  local  Internet  Service  Provider  (ISP).  The  data  rates 
encountered  are  found  in  Table  5.1. 


From 

To 

File  Size 
(bytes) 

Time 

(min) 

Data  Rate 
(Kbytes/sec) 

Data  Rate 
(Kbytes/min) 

SNMP 

Monitored? 

WHOI- 

Linux 

324,391 

32 

0.17 

10.2 

Yes 

WHOI 

Linux 

324,391 

28.8 

0.22 

13.2 

Yes 

WHOI 

Linux 

324,391 

18.8 

0.28 

16.8 

Yes 

HP 

Linux 

427706 

24 

0.29 

17.4 

Yes 

HP 

Linux 

427,706 

20 

0.35 

21 

Yes 

Win95 

HP 

16.5 

0.43 

25.8 

Yes 

HP 

Win95 

5.4 

0.36 

21.6 

Yes 

Win95 

HP 

106,614 

9.2 

0.19 

11.4 

Yes 

WHOI 

Win95 

398,243 

16.6 

0.40 

24 

No 

WHOI 

Win95 

15.6 

0.43 

25.8 

No 

WHOI 

Win95 

398,243 

15.2 

0.55 

33.0 

No 

Table  5.1  Data  Transfer  Rates 


Conducting  continuous  network  management  (Section  D)  while  performing  other 
functions  like  file  transfer  will  have  some  impact  on  the  data  transfer  rate.  To  illustrate 
this  impact,  consider  the  following  exercise:  An  SNMP  request/response  query  is 
approximately  82  bytes  or  656  bits  [Ref  13].  Considering  that  a  conservative  estimate  of 
the  reply/response  cycle  over  the  satellite  link  is  2.4  seconds,  potentially  273  bps  may  be 
consumed  by  network  management.  This  number  represents  roughly  six  percent  of  the 


54 


available  bandwidth  provided  by  a  4800  bps  connection.  Despite  this  estimation,  the 
values  of  Table  5.1  provide  no  direct  correlation  between  the  rates  of  managed  and 
unmanaged  data  transfers.  Obviously  Table  5.1  presents  only  a  small  sample  of  data 
transfer  rates  and  these  rates  are  affected  by  several  factors  other  than  network 
management  (server  loads,  network  traffic,  etc.).  Clearly,  a  more  rigorous  investigation 
of  the  overhead  associated  with  eonstant  network  monitoring  is  warranted. 

2.  Smooth  Transition  Between  Voice  and  Data  Communications 

One  notable  feature  of  the  AMSC  Tracphone  is  its  ability  to  easily  switch  between 
data  and  voice  commimications.  Although  voice  and  data  cannot  be  transmitted 
simultaneously,  the  operator  can  switch  to  voice  operations  simply  by  using  the 
Tracphone  handset;  pushing  the  “END”  button  on  the  handset  terminates  data  operations 
and  commences  voiee  communieations.  For  a  ship  with  minor  data  transfer  requirements 
the  AMSC  Tracphone  can  serve  as  a  backup  voice  communications  system. 

C.  HPOV  NETWORK  MONITORING 

This  section  discusses  the  information  HPOV  is  able  to  extract  from  the  shipboard 
SNMP  agent.  A  listing  of  all  MIB-II  variables  and  instances  extracted  from  the  shipboard 
computer  is  given  in  Appendix  D. 

1.  PoUNode 

One  of  the  most  powerful  and  fundamental  functions  HPOV  offers  is  that  of  Poll 
Node.  The  Poll  Node  command  can  be  initiated  from  the  toolbar  by  selecting  “Fault”  and 
then  “Network  Configuration:  Poll  Node.”  Using  the  Poll  Node  command,  a  network 
administrator  can  direct  the  NMS  to  update  all  available  information  on  a  given  SNMP 
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agent.  Poll  Node  surveys  network  devices  for  their  SNMP  capabilities,  an  agent’s  polling 
parameters,  and  which  SNMP  applications  the  agent  can  support.  Figures  5.1  displays 
the  results  of  a  Poll  Node  command  performed  on  a  LINUX  agent.  Note  that  from  Figure 
5.1  one  can  observe  that  Shipboard  Linux  computer  supports  both  SNMPvl  and 
SNMPv2C. 
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File  View 


Name  or  IP  Address 


^lcl71*cc*nps*navy*mil 


Poll  Results 


12:57:11 


12:57:13 

12:57:13 

12:57:13 

12:57:13 

12:57:13 

12:57:16 

12:57:16 

12:57:18 

12:57:21 

12:57:28 

12:57:30 

12:57:39 

12:57:41 

12:57:41 

12:57:43 

12:57:45 

12:57:48 

12:57:50 

12:57:58 

12:58:01 

12:58:01 

12:58:03 

12:58:03 

12:58:06 

12:58:06 

12:58:06 

12:58:06 

12:58:06 

12:58:06 


Interface  131  ♦1204.50 ^171  (currently  Normal) 


responded  to  ping 
Current  polling  parameters 

scheduled  configuration  check  at  Sun  Aug  30  12:51:54  1998 
scheduled  discovery  poll  at  Sat  Aug  29  12:58:27  1998 
Determine  supported  SNMP  versions 
Supported  versions:  SNMPvl  SNMPv2C 
Get  system  identifier 
Get  system  description 
Get  IP  address  table 
Get  number  of  interfaces 
Get  interfaces  table 
Get  interfaces  table  extensions 
table  empty 

Get  IP  forwarding  status 
Get  system  location 
Get  system  contact 
Get  default  routing  entry 
Get  routing  table 
Get  IP  Address  Translation  Table 
table  empty 
Get  ARP  table 
table  empty 
Get  station  type 
SNMP  error:  no  such  name 
Verify  node  name 

node  name  verified  to  be  slcl7l4.cc*nps*,navy*mil 
Checking  interface  subnet  masks 
Bad  subnet  mask  255*255*0*0  on  interface  pppO  <131 *120 *50 *171 
*****  End  of  demand  poll  for  node  slcl71*cc*nps*navy*rail 


57 


2.  System  Information 

System  information  is  another  standard  menu  selection  provided  by  HPOV.  This 
information  can  be  found  by  selecting  “Configuration”  in  the  tool  bar,  then  “System 
Information.”  Representative  System  Information  results  are  shown  in  Figure  5.2. 


File  View 


Help 


Name  or  IP  Address 


^Icl71*cc*nps4navy4mil 


iSystem  Name 


;  131.120.63.227 


System  Description 
System' Contact 
System  Location 
System  Object  ID 
System  Up  Time 


Linux  version  2*0*32  (root^porky^redhat^com)  (ycc  version  2*7*2-.3) 
Christopher  L*  Pratt 
Root  Hall  Room  222 

*iso*or9*dod*internet^private*enterprises*1575*l*5 
<677028)  1:52:50.28 


Messages 


Close 

Restart 

^mssm 


Figure  5.2  The  HPOV  System  Information  Table 


As  can  be  seen  from  Figure  5.2,  the  System  Information  command  returns  six 
instances  from  the  agent.  The  information  formd  in  system  information  is  a 
representation  of  the  MIB-II  systems  group.  System  Name  denotes  the  administratively 
assigned  name  of  the  SNMP  agent.  The  System  Description  field  denotes  the  operating 
system  of  agent  computer.  The  System  Contact  and  System  Location  fields  identify  who 
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to  contact  about  the  system  and  where  the  system  is  located  respectively.  The  System 
Object  ID  represents  Red  Hat’s  authoritative  network  management  subsystem.  System 
Up  Time  denotes  the  elapsed  time  since  the  system  was  last  re-initialized. 

3.  Network  Configuration 

Another  standard  service  provided  hy  HPOV  is  Network  Configuration.  Network 
Configuration  is  broken  into  three  sections:  Address  Resolution  Protocol  (ARP)  Cache, 
Routing  Table,  and  Services.  In  the  case  of  the  shipboard  computer,  the  ARP  Cache 
Table  contains  no  information. 

a.  Routing  Table 

The  routing  table  command  provides  information  about  possible 
destinations  and  how  to  reach  them  [Ref.  13].  This  information  is  useful  for  diagnosing 
connectivity  problems  [Ref.  17].  From  Figure  5.3  one  can  observe  that  the  default 
destination  gateway  is  tsb.cc.nps.navy.mil.  This  default  gateway  is  the  route  the  SNMP 
agent  will  use  when  it  cannot  find  a  specific  route.  The  destination  can  be  one  of  three 
types:  direct  (directly  connected  to  a  LAN),  invalid  (not  currently  available)  or  remote 
(through  a  remote  gateway).  Interface  indicated  the  name  of  the  interface  used  to  reach 
the  destination  [Ref.  17]. 
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Routinq  Table  :  slc:179^cc*n 


File  View 


Help 


Name  or  IP  Address 


^lcl79*cc.nps.nawa«mi 1 


Destination 


Gateway 


Type 


Mask 


Interface 


default  tsb,cc,nps»navy,mil  remote 

tsb,cc*nps.navy,mil  0  direct 


0,0.0.0  PPPO 

255.255.255,255  pppO 


Messages 


Figure  5.3  The  HPOV  Routing  Table 


b.  System  Services 

The  System  Services  table  provides  information  on  port  usage  by  the  agent 
computer.  “This  operation  is  useful  for  determining  what  services  a  node  is  configured  to 
support”  [Ref  17].  In  Figure  5.4,  one  can  observe  that  eight  TCP  ports  and  three  UDP 
ports  are  in  use.  These  port  numbers  correlate  directly  to  processes  running  on  the  agent 
computer.  The  service  column  of  the  table  lists  the  service  for  which  the  node  is  listening 
(if  known). 
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erv  i  ces  :  s  1  cl71  *  cc ♦  nps  ^  na vm + ro  i  1 


File  View 


Help 


Name  or  IP  Address 


^Icl71*cc*nps4navy*mil 


Protocol 

Port 

Service 

Itcp 

ftp 

tcp 

22 

tcp 

23 

telnet 

tcp 

111 

portmap 

tcp 

139 

netbios^ssn 

tcp 

515 

printer 

tcp 

5432 

tcp 

GOOO 

udp 

111 

portmap 

udp 

161 

snmp 

udp 

514 

syslog 

Messages 


Close 

Restart 

Figure  5.4  The  HPOV  Services  Table 


D.  MONITORING  FILE  TRANFERS 

This  section  illustrates  the  real-time  monitoring  of  an  SNMP  agent  from  a  remote 
network  management  station.  During  a  file  transfer,  the  HPOV  network  node  manager  is 
observing  IP  packet  and  TCP  segment  information.  In  this  example,  a  324  Kbytes  file  is 
being  transferred  from  a  WHOI  file  server  to  the  NPS  shipboard  computer.  Figures  5.5 
and  5.6  show  the  SNMP  monitoring  of  this  file  transfer  from  the  HPOV  system.  Using 
this  fimctionality,  a  shore-based  network  administrator  can  monitor  ship-to-shore  data 
transfers  in  real  time. 
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Six  variables  are  monitored  in  these  graphs.  The  variables  are  as  follows: 

ipInReceives  (MIB  1.3.6.1.2.4.3):  A  counter  which  gives  the  total 
number  of  input  datagrams  received  from  interfaces,  including  those  received 
in  error  [Ref  18]. 

-  ipInHdrErrors  (MIB  1. 3.6.1. 2.4.4):  A  counter  which  gives  the  number  of 
input  datagrams  discarded  due  to  errors  in  IP  header  [Ref  18]. 

ipInAddrErrors  (MIB  1.3.6.1.2.4.5):  A  counter  which  gives  the  number 
of  input  datagrams  discarded  because  the  P  address  in  the  destination  field 
was  not  valid  to  be  received  at  this  entity  [Ref  18]. 

-  ipInDiscards  (MIB  1.3.6.1.2.4.8):  A  counter  which  gives  the  number  of 
input  P  datagrams  for  which  no  problems  were  encountered  to  prevent  their 
continued  processing  but  which  were  discarded  [Ref  18]. 

tcpInSegs  (MIB  1.3.6.1.2.6.10):  A  counter  which  provides  the  total 
number  of  segment  received,  including  those  received  in  error  [Ref  18]. 

-  tcpRetransSegs  (MB  1.3.6.1.2.6.12):  A  counter  which  gives  the  total 
number  of  retransmitted  segments  [Ref  18]. 
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Figure  5.5  IP  Packet  Monitoring  of  File  Transfer  from  WHOI  to  Linux  Agent 
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Figure  5.6  TCP  Segment  Monitoring  of  File  Transfer  from  WHOI  to  Linux  Agent,  note 
that  the  initial  tcpRetransSegs  are  probably  TCP  retransmissions  stacking  up  as  they 
time  out.  Initial  TCP  timeouts  may  be  less  than  the  propagation  time  through  the  satellite 
link  while  the  timeouts  of  later  packets  are  adjusted  to  be  larger  than  the  satellite  link 

delay  time. 


E.  PROBLEMS 

1.  Latency  and  Timeouts 

The  data  response  latency  of  roughly  2.5  seconds  can  lead  to  SNMP  request  time¬ 
outs.  Time-outs  represents  the  amounts  of  time  (in  seconds)  that  HPOV  will  wait  for  a 
response  before  retrying  the  SNMP  request.  If  HPOV  encounters  three  consecutive 
timeouts,  it  will  suspend  polling  of  the  node.  Suspension  of  polling  can  be  avoided  by 
setting  the  HPOV  polling  interval  to  a  significantly  long  interval.  Selecting  “Options” 
then  “Configure  Node  Status  Polling  Intervals”  sets  node  polling  intervals. 
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Figure  5.7  shows  the  HPOV  SNMP  Configuration  window.  Note  that  the  entry 
131.120.50.*  has  a  time-out  of  10  seconds.  This  wildcard  value  represents  all  nodes  in 
the  NPS  modem  bank.  Such  a  configuration  prevents  the  time-out  of  the  shipboard 
SNMP  agent  regardless  of  which  BP  it  is  dynamically  assigned. 


Figure  5.7  The  HPOV  SNMP  Configuration  Window 
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2.  Dynamically  Assigned  IP  Addresses 

Dynamically  assigned  IP  addresses  present  another  problem  for  network 
management.  HPOV  is  designed  to  monitor  a  stable  network;  that  is,  a  network  with 
fixed  IP  addresses  and  devices  that  are  consistently  on  the  network.  The  shipboard 
computer,  however,  is  expected  to  dial  in,  receive  a  dynamic  IP  address,  exchange  data, 
and  disconnect.  Total  connection  time  for  the  ship  may  be  as  little  as  thirty  minutes. 
HPOV,  however,  may  require  several  hours  to  discover  a  new  network  node. 

To  increase  the  firequency  with  which  HPOV  will  discover  new  nodes  (and 
increase  the  chance  that  HPOV  will  discover  the  shipboard  computer),  HPOV  can  be 
configured  to  rapidly  poll  nodes.  Unfortunately,  rapid  polling  has  limitations  as  well.  If 
the  polling  interval  is  too  fi-equent,  HPOV  will  never  discover  the  node;  a  new  polling 
cycle  will  begin  before  the  prior  polling  iteration  is  complete.  Thus  some  nodes  are 
polled  rapidly  while  others  are  not  polled  at  all. 

3.  Node  Merge 

A  unique  problem  for  the  NPS  SeaNet  laboratory  is  that  the  shipboard  computer  is 
also  the  NPS  LAN  node  131.120.63.227  (Figure  5.8).  When  the  shipboard  computer 
dials  into  the  NPS  modem  bank  (Figure  5.9),  HPOV  will  discover  that  the  two  nodes  (the 
modem  bank  node  and  the  LAN  node)  represent  the  same  computer.  HPOV  will  then 
merge  the  nodes,  representing  them  as  a  modem  bank  node  in  both  the  131.120.63  and 
131.120.50  subnetworks  (Figures  5.10  and  5.1 1  respectively).  Once  the  nodes  are 
merged,  HPOV  recognizes  that  both  are  SNMP  supported  and  SNMP  information  can  be 
gathered  fi'om  either  node  representation. 
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The  problem  is  that  after  disconnecting  from  the  NFS  modem  bank,  the 
131.120.63  node  never  relinquishes  its  status  as  a  modem  bank  node;  that  is,  once  the 
node  131.120.63.227  is  converted  to  slcl70,  it  never  reverts  back  to  131.120.63.227.  It 
may  take  several  hours  (or  even  several  days)  for  HPOV  to  realize  that  the  modem  bank 
node  no  longer  represents  the  LAN  node  and  rediscover  the  LAN  node. 


Figiue  5.8  The  131.120.63  Subnet  Prior  to  Node  Merge 
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Figure  5.9  NPS  Modem  Bank  Prior  to  Node  Merge  (Note  node  slcl70) 
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Figure  5.10  The  131.120.63  Subnet  After  Node  Merge  (Note  that  node  131.120.63.227  is 

now  represented  by  sic  1 70) 
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Figure  5.11  The  NFS  Modem  Phone  Bank  After  Node  Merge 
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F. 


SUMMARY 


HPOV  is  a  powerful  tool  for  remote  network  management.  Inherent  UPOV 
functions  such  as  Poll  Node,  Routing  Table,  and  System  Services  provide  easy 
monitoring  of  SNMP  agents.  Real  time  monitoring  of  SNMP  variables  also  provides  a 
powerful  tool  for  network  administrators  to  gather  SNMP  information.  HPOV  does  have 
some  difficulties  when  monitoring  the  NPS  shipboard  computer,  however.  Latency 
imposed  by  satellite  connections  can  lead  to  HPOV  time-outs.  HPOV  also  has  difficulty 
in  monitoring  devices  with  dynamically  assigned  IP  addresses.  This  difficulty  is 
compounded  by  the  relatively  short  connection  times  it  is  anticipated  that  ships  will 
make.  Further  work  is  needed  to  resolve  these  difficulties. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  RESEARCH  CONCLUSIONS 

This  thesis  investigates  the  concept  of  remote  network  management  over  a 
satellite  link.  It  surveys  the  current  SeaNet  program,  discusses  the  principles  of  network 
management,  and  introduces  the  NFS  SeaNet  laboratory.  Finally,  this  thesis  presents 
initial  findings  and  problems  associated  with  actual  remote  network  management. 

Maritime  commimications  tend  to  be  expensive  and  of  limited  capacity.  The 
SeaNet  program  is  building  an  infi-astmcture  to  provide  Internet  access  to  maritime 
vessels  at  a  reasonable  cost.  One  aspect  of  the  SeaNet  program  is  remote  network 
management.  Remote  network  management  alleviates  network  administration  burdens 
firom  shipboard  personnel  and  allows  them  to  concentrate  on  more  mission  specific 
functions.  It  also  allows  for  dedicated  monitoring  and  analysis  from  the  shore-based 
management  site.  This  capability  will  support  the  SeaNet  program  by  providing  the 
maritime  research  community  with  a  flexible  and  cost-effective  tool  for  monitoring  sea- 
based  assets. 

The  NFS  SeaNet  lab  is  investigating  emerging  technologies  for  the  SeaNet 
program.  Using  an  IBM  compatible  FC,  HF-Unix  workstation  running  HFOV,  and  a 
KVH  Tracphone,  the  NFS  SeaNet  laboratory  is  able  to  establish  a  point-to-point 
connection  via  an  AMSC  satellite  connection.  Remote  network  management  is  possible, 
but  it  is  not  without  difficulties.  HFOV  encounters  difficulties  when  dealing  with  latency 
and  dynamically  assigned  IF  addresses. 
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B.  RECOMMENDATIONS  FOR  FURTHER  RESEARCH 

1.  Remote  Network  Monitoring 

The  next  logical  step  for  the  NFS  SeaNet  laboratory  involves  investigating  the  use 
of  RMON  probes  on  shipboard  network  devices.  An  RMON  probe  can  gather 
information  on  the  shipboard  LAN  while  the  ship  is  disconnected  from  the  shore-based 
network  management  station.  When  the  ship  conducts  data  transfers,  condensed  RMON 
data  can  be  exported  to  the  shore-based  site  for  analysis. 

2.  Network  Management  of  Actual  Maritime  Vessels 

Another  logical  step  for  the  NFS  SeaNet  laboratory  involves  the  monitoring  of 
actual  shipboard  SNMF  agents.  This  task  involves  configuring  the  NMS  to  observe 
WHOI  vessels  through  Omnet.  When  ships  connect  to  the  Omnet  site,  the  NMS  would 
be  able  to  gather  information  from  the  vessels.  This  project  would  also  include 
monitoring  certain  aspects  of  the  Omnet  shore  station.  WHOI  and  Omnet  representatives 
have  favorably  received  suggestions  for  this  project. 

3.  Discovery  of  Dynamically  Assigned  IP  Addresses 

The  difficulty  HFOV  encounters  with  dynamically  assigned  P  addresses  has  not 
been  fully  addressed.  For  HFOV  to  function  as  a  NMS  for  agents  with  dynamically 
assigned  P  addresses,  it  must  acknowledge  the  agents  when  they  first  dial  in  to  the 
network.  This  project  would  involve  creating  a  way  for  the  shipboard  agent  to  send  a 
message  to  the  NMS  as  soon  as  the  agent  connected  to  the  network.  The  NMS  would, 
upon  receipt  of  message,  poll  the  P  address  for  SNMF  information.  This  way  all  SNMF 
information  could  be  gathered  before  shipboard  computer  disconnects  from  the  network. 
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4.  Customization  of  MIB  variables  for  SeaNet  SNMP  agents 

Research  is  needed  to  determine  exactly  what  kind  of  information  should  be 
gathered  from  maritime  vessels  and  how  this  information  can  be  used.  This  project 
would  involve  the  examination  of  MIB  variables  beyond  the  MIB-II  subset.  Study  would 
include  evaluation  of  MEBs  developed  by  private  enterprises  and  the  possible  creation  of 
MIBs  unique  to  the  SeaNet  project. 

5.  Evaluation  of  Future  SeaNet  Equipment 

This  study  would  involve  evaluation  of  technologies  beyond  those  currently  being 
used  in  Ihe  SeaNet  program.  Current  initiatives  are  vmderway  for  NFS’s  evaluation  of  a 
56kbyte  satellite  link  provided  by  AMSC. 

6.  Development  of  a  Bandwidth  Budget 

This  project  would  develop  metrics  for  estimating  the  bandwidth  requirement  of  a 
SeaNet  vessel.  It  would  involve  studying  current  shipboard  LANs,  estimating  the  SNMP 
traffic  across  the  LAN  and  SNMP  traffic  across  the  satellite  connection.  Questions  to  be 
answered  include:  what  overhead  is  associated  with  remote  network  management  and 
does  this  overhead  detract  from  data  transfer  operations?  This  study  would  directly 
expand  on  the  throughput  and  latency  issues  introduced  in  Chapter  5. 
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APPENDIX  A.  WINDOWS  95  CONFIGURATION 


This  appendix  describes  how  to: 

1 .  Setup  a  serial  connection  between  the  KVH  Transceiver  Unit  (TU)  and  a  PC 
using  an  RS-232  cable. 

2.  Use  the  Windows95  HyperTerminal  to  check  the  serial  connection  between 
the  PC  and  the  KVH  Transceiver  Unit  (TU) 

3.  Setup  Windows  Dial-Up  Networking  to  use  the  KVH  Tracphone  to  dial  an 
ISP. 

4.  Setting  up  a  serial  connection  between  a  PC  and  the  KVH  Transceiver 
Unit(TU) 

This  section  should  be  used  in  conjunction  with  the  KVH  Tracphone  manual.  The 
RS-232  is  recommended  to  be  6  feet  in  length  or  LESS.  The  pin  configuration  of  an  RS- 
232  cable  is  DB9F  to  DB25M,  which  indicates  a  9  pin  female  end  and  a  25  pin  male  end 
respectively.  Before  connecting  the  cable  between  the  computer  and  the  TU  both  the 
computer  and  the  Tracphone  must  be  off.  The  cable’s  9-pin  female  end  connects  to  the 
computer’s  9  Pin  male  serial  port. 

NOTE!  When  connecting  the  cable,  identify  which  computer  serial  port  you  are 
connecting  the  cable  to  i.e.,  COMl,  COM2,  etc.  The  port  will  be  labeled  on  the  back  of 
the  computer  or  in  your  computer  documentation.  This  information  will  be  needed  later 
in  the  setup. 

The  cable’s  25  pin  male  end  connects  to  the  KVH  TU’s  25  pin  female  port.  This 
will  establish  a  serial  connection  to  the  KVH  TU.  The  KVH  TU  accepts  “AT” 
commands  like  any  standard  modem.  The  KVH  Tracphone  manual  recommends 
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powering  up  the  computer  first  and  then  the  KVH  Tracphone. 

1 .  Power  up  the  Computer 

2.  Power  up  the  KVH  Tracphone  Antennae  (Above  deck  equipment) 

3 .  Power  up  the  KVH  Transceiver  Unit  (Below  deck  Equipment) 

-  RIGHT  CLICK  “My  Computer”  (click  the  right  mouse  button). 


iMv  Computer 

tS 

Network 

Neighborhoo( 

Recycle  Bin 

/ 

Properties 

LEFT  CLICK  (click  the  left  mouse  button)  to  open  the  “System  Properties” 
dialog  box. 
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LEFT  CLICK  on  the  “Device  Manager”  tab  in  the  “System  Properties”  Dialog 
box. 

LEFT  CLICK  the  “+”  symbol  next  to  “Ports  (COM  &  LPT)”  to  expand  the 
“Ports  (COM  &  LPT)”  section. 

Identify  the  Communication  Port  that  you  have  used  to  connect  your  computer 
to  the  KVH  TU  with  an  RS-232  cable.  In  our  example,  it  is  on 
“Communications  Port  (COMl)”. 

LEFT  CLICK  on  the  correct  Communications  Port  to  HIGHLIGHT  it. 


LEFT  CLICK  the  “Properties”  button  below  the  “Device  Manager”  window. 
This  will  open  the  “Conmumication  Port  (COMl)  Properties”  dialog  box. 
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LEFT  CLICK  the  “Port  Settings”  tab  on  the  “Communications  Port  (COMl) 
Properties”  dialog  box. 


SELECT  the  following  values  in  the  “Port  Settings”  drop  down  boxes  (LEFT 
CLICK  the  drop  down  box  arrow,  HIGHLIGHT  the  desired  value  and  LEFT 
CLICK): 


Bits  per  second: 
Data  bits: 

Parity: 

Stop  bits: 

Flow  control: 


4800 

8 

None 

1 

Xon  /  Xoff 


LEFT  CLICK  the  “Advanced”  button  to  open  the  “Advanced  Port  Settings” 
dialog  box. 
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LEFT  CLICK  the  check  box  “Use  FIFO  buffers  (requires  16550  compatible 
UART)”.  If  the  box  is  already  has  a  check  mark  in  it  you  can  ignore  this  step. 

LEFT  CLICK  &  HOLD  DOWN  the  buton  to  adjust  the  slide  bars. 

SET  the  “Receive  Buffer:”  and  the  “Transmit  Buffer:”  to  the  3^**  tick  position 
from  the  left  as  shown  by  adjusting  the  slide  bars. 


LEFT  CLICK  the  “OK”  button  in  the  “Advanced  Port  Settings”  dialog  box. 
This  will  close  the  “Advanced  Port  Settings”  dialog  box  and  return  you  to  the 
“Communication  Port  (COMl)  Properties”  dialog  box. 

LEFT  CLICK  the  “OK”  button  in  the  “Conunimication  Port  (COMl) 
Properties”  dialog  box.  This  will  close  the  “Communication  Port  (COMl) 
Properties”  dialog  box  and  return  you  to  the  “System  Properties”  dialog  box. 

LEFT  CLICK  the  “OK”  button  in  the  “System  Properties”  dialog  box.  This 
will  close  the  “System  Properties”  dialog  box  and  return  you  to  the  desktop. 

Now  the  port  is  configured  to  communicate  with  the  KVH  Transceiver  Unit 
using  standard  “AT”  modem  commands. 
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2.  Using  HyperTerminal  to  test  the  KVH  TU  configuration 
If  HyperTerminal  is  installed  on  your  Win95  computer,  then  the  program  will  be 
located  in  the  following  location. 

C:\Program  Files\Accessories\HyperTerminal\Hypertrm.exe. 

If  HyperTerminal  is  NOT  installed  use  Windows95  Help  to  get  information  on 
“Adding  HyperTerminal”. 

Running  HyperTerminal 


-  LEFT  CLICK  “Start” 

-  HIGHLIGHT  “Programs”,  HIGHLIGHT  “Accessories”,  HIGHLIGHT 
“HyperTerminal”  and  LEFT  CLICK  to  open  the  “HyperTerminal”  folder 
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DOUBLE  LEFT  CLICK  on  the  “Hypertnn.exe”  Icon  (shown  below)  in  the 
“HyperTerminal”  folder.  This  will  open  the  “Connection  Description”  dialog 
box 


Hypertnn.exe 


-  Enter  a  name  into  the  “Name”  field  (Any  name).  Here  the  name  “KVH 
Transceiver  Unit  Test”  is  used.  Pick  a  pretty  icon.  LEFT  CLICK  the  “OK” 
button.  This  will  open  the  “Phone  Number”  dialog  box. 
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In  the  “Connect  using”  drop  down  box  SELECT  the  COM  Port  where  the 
KVH  TU  is  connected.  Here  it  is  “Direct  to  Com  1”.  Use  the  drop  down  box 
to  see  all  of  the  possible  choices.  Once  you  choose  “Direct  to  Com  x”  all  the 
other  fields  will  become  dark  indicating  that  no  other  information  is  needed. 
LEFT  CLICK  the  OK  button.  This  will  open  the  “COMl  Properties”  dialog 
box. 


82 


SELECT  the  following  values  in  the  “Port  Settings”  drop  down  boxes: 
Bits  per  second:  4800 

Data  bits:  8 

Parity:  None 

Stop  bits:  1 

Flow  control:  Xon  /  Xoff 

LEFT  CLICK  the  “Advanced”  button.  This  will  open  the  “Advanced  Port 
Settings”  dialog  box. 
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-  LEFT  CLICK  the  check  box  “Use  FIFO  buffers  (requires  16550  compatible 
UART)”.  If  the  box  is  already  has  a  check  mark  in  it  you  can  ignore  this  step. 

-  SET  the  “Receive  Buffer:”  and  the  “Transmit  Buffer:”  to  the  3'**  tick  position 
from  the  left  as  shown  below  by  adjusting  the  slide  bars. 


LEFT  CLICK  the  “OK”  button.  This  will  close  the  Advanced  Port  Settings” 
dialog  box  and  return  you  to  the  “COMl  Properties”  dialog  box. 

LEFT  CLICK  the  “OK”  button.  This  will  close  the  “COMl  Properties”  dialog 
box  and  open  the  HyperTerminal  main  screen. 
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You  are  connected  now.  To  verify,  look  for  a  timer  that  is  counting  in  the 
lower  left  hand  comer.  There  will  also  be  a  blinking  cursor. 


-  To  test  your  connection  TYPE  “AT”  and  hit  “ENTER”,  the  screen  will 
respond  with  “OK”.  This  means  that  the  KVH  TU  is  properly  setup  for  use 
with  your  PC.  For  more  commands  consult  the  AMSC  Technical  Bulletin 
Subject:  “Using  Circuit  Switched  Data  on  the  AMSC  System”. 
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LEFT  CLICK  “Yes”  to  disconnect. 


LEFT  CLICK  “Yes”  to  save  the  session  settings,  this  will  close 
Hyperterminal  and  return  you  to  the  desktop. 


HyperT  er  minal 


Win95  Dial-Up  Networking  Setup  for  a  PPP  connection  with  a  ISP  through  the 
KVH  Tracphone 

In  order  to  set  up  Dial-Up  Networking  you  will  need  the  following  information: 

-  A  dial  up  account  with  an  Internet  Service  Provider  (ISP). 

-  ISP  phone  niunber  including  area  code. 

-  ISP  Primary  and  Secondary  Domain  Name  Server  (DNS). 

-  The  login  name  and  password  to  access  the  account. 


-  To  start  Dial-Up  Networking  LEFT  CLICK  “Start”,  HIGHLIGHT 

“Accessories”,  HIGHLIGHT  “Dial-Up  Networking”,  and  LEFT  CLICK.  This 
will  open  the  “Dial-Up  Networking”  Folder. 


-  DOUBLE  LEFT  CLICK  on  the  “Make  New  Connection”  Icon.  This  will  open 
the  “Make  New  Connection”  dialog  box. 


[Mal^  New! 
jConnectionl 
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TYPE  in  a  name  for  the  connection  you  are  creating.  Here  it  is  called  “KVH 
Connection”.  In  the  “Select  a  device”  drop  down  box  SELECT  “Standard 
9600  bps  Modem”.  LEFT  CLICK  the  “Next”  button  to  continue. 


-  TYPE  in  the  phone  number  and  coimtry  code  and  LEFT  CLICK  ‘TSfext” 


Make  New  Connection 
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LEFT  CLICK  “Finish”  to  complete  the  initial  setup  of  the  Dial-Up 
Connection.  This  will  return  you  to  the  “Dial-Up  Networking”  folder  where 
the  new  “KVH  Connection”  will  now  be  visible. 


RIGHT  CLICK  the  new  “KVH  Connection”  icon,  HIGHLIGHT  “Properties”, 
and  LEFT  CLICK.  This  will  open  the  “KVH  Connection”  dialog  box. 


VERIFY  the  information  and  then  LEFT  CLICK  the  “Configure”  button,  this 
will  open  the  “Standard  9600  modem  Properties”  dialog  box. 


VERIFY  that  the  correct  COM  port  is  selected  in  the  “Port”  field.  Here  it  is 
“Communication  Port  (COMl)”.  This  is  the  port  where  the  KVH  TU  is 
connected.  Select  the  appropriate  “Maximum  speed”,  for  the  KVH  Tracphone 
is  4800  bps,  so  select  4800.  LEFT  CLICK  the  “Coimection”  tab. 
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SELECT  the  following  values  in  the  “Connection”  tab  drop  down  boxes: 
Data  bits:  8 

Parity:  None 

Stop  bits:  1 

LEFT  CLICK  the  “Port  Settings’  button.  This  will  open  the  “Advanced  Port 
Settings”  dialog  box. 


LEFT  CLICK  the  check  box  “Use  FIFO  buffers  (requires  16550  compatible 
UART)”.  If  the  box  is  already  has  a  check  mark  in  it  you  can  ignore  this  step. 

SET  the  “Receive  Buffer:”  and  the  “Transmit  Buffer:”  to  the  3"^^^  tick  position 
from  the  left  as  shown  below  by  adjusting  the  slide  bars. 

LEFT  CLICK  the  “OK  “  button.  This  will  return  you  to  the  “Standard  9600 
bps  Modem  Properties”  dialog  box  and  the  “Connection”  tab. 
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I  Advanced  Port  Settings 


LEFT  CLICK  the  “Advanced”  button.  This  will  open  the  “Advanced 
Connection  Settings”  dialog  box. 


LEFT  CLICK  “Use  Flow  Control”  check  box  and  LEFT  CLICK  the  “Software 
(XON/XOFF)”option  button.  LEFT  CLICK  the  “OK”  button.  This  will 
return  you  to  the  “Standard  9600  bps  Modem  Properties”  dialog  box  and  the 
“Connection”  tab. 
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LEFT  CLICK  the  “Options”  tab 


-  LEFT  CLICK  the  “Display  modem  status”  checkbox.  NOTE!  If  you  are 
connecting  to  a  UNIX  based  system  LEFT  CLICK  the  “Bring  up  terminal 
window  after  dialing”  checkbox,  otherwise  leave  it  blank.  LEFT  CLICK  the 
“OK”  button.  This  will  return  you  to  the  “KVH  Coimection”  dialog  box. 
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LEFT  CLICK  the  “Server  Types”  tab. 


SELECT  “PPP:  Windows  95,  Windows  NT  3.5  Internet”  in  the  “Type  of  Dial- 
Up  Server:”  drop  down  box.  LEFT  CLICK  the  TCP/IP  checkbox  under  the 
“Allowed  network  protocols”  section.  LEFT  CLICK  the  “TCP/P  Settings 
button.  This  will  open  the  “TCP/IP  Settings”  dialog  box. 
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-  LEFT  CLICK  the  “Server  assigned  IP  address”  option  button.  LEFT  CLICK 
the  “Server  assigned  name  server  address”  option  button.  LEFT  CLICK  the 
“Use  IP  header  compression”  check  box.  LEFT  CLICK  the  “Use  default 
gateway  on  remote  network”  check  box.  LEFT  CLICK  the  “OK”  button. 
This  will  return  you  to  the  “KVH  Connection”  dialog  box. 
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LEFT  CLICK  the  “OK”  button.  This  will  return  you  to  the  “Dial-Up 
Networking”  folder 


-  Dial-Up  Networking  for  the  KVH  Tracphone  is  complete.  To  connect 

DOUBLE  LEFT  CLICK  on  the  “KVH  Connection”  icon  within  the  “Dial-Up 
Networking”  folder. 


Adding  a  Standard  modem  to  Win95  to  utilize  Dial-Up  Networking 

-  LEFT  CLICK  “Start”,  HIGHLIGHT  “Control  Panel”,  and  LEFT  CLICK.  This 
will  open  the  “Control  Panel”  folder. 
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-  DOUBLE  LEFT  CLICK  the  “Add  New  Hardware”  icon.  This  will  open  the 
“Add  New  Hardware  Wizard”  dialog  box. 


Control  Panel 


32bit  ODBC  3Com  PACE  Accessibility 
Config  Options 


Add  N  ew 
Hardware 


Add/Remove  Date/Time 
Programs 


-  LEFT  CLICK  the  “Next”  button  to  continue. 
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LEFT  CLICK  the  “No”  check  box  so  Win95  will  not  search  for  new  hardware. 
LEFT  CLICK  the  “Next”  button  to  continue. 


-  LEFT  CLICK  the  “Modem”  icon  to  HIGHLIGHT  it.  LEFT  CLICK  the 
“Next”  button  to  continue. 
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LEFT  CLICK  the  “Don’t  detect  my  modem;  I  will  select  it  from  a  list.”  check 
box.  LEFT  CLICK  the  “Next”  button  to  continue. 


LEFT  CLICK  the  “(Standard  Modem  Types)”  in  the  “Manufacturers”  (Left) 
column  to  HIGHLIGH  it.  LEFT  CLICK  the  “Standard  9600  bps  Modem”  in 
the  “Models”  column  (Right)  to  HIGHLIGHT  it.  LEFT  CLICK  the  “Next” 
button  to  continue. 
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-  LEFT  CLICK  “Communications  Port  (COMl)”  in  the  “Select  the  port  to  use 
with  this  modem”  to  HIGHLIGHT  it.  (NOTE!  Select  the  port  on  your 
computer  where  the  cable  to  the  KVH  Tracphone  is  connected.)  LEFT 
CLICK  the  “Next”  button  to  continue. 


LEFT  CLICK  the  “Finish”  button  to  continue. 
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Verifying  the  Modem  Setup  in  Control  Panel 


-  LEFT  CLICK  “Start”,  fflGHLIGHT  “Control  Panel”,  and  LEFT  CLICK.  This 
will  open  the  “Control  Panel”  folder. 


-  DOUBLE  LEFT  CLICK  the  “Modems”  icon  to  open  the  “Modem  Properties” 
dialog  box. 
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Verify  that  the  “Standard  9600  bps  Modem”  is  listed  under  the  “The  following 
modems  are  set  up  on  this  computer.”  LEFT  CLICK  the  “OK”  button  to 
return  to  the  “Control  Panel”  folder. 


LEFT  CLICK  “File”  from  the  menu,  HIGHLIGHT  “Close”,  and  then  LEFT 
CLICK  to  close  the  “Control  Panel”.  This  will  return  you  to  the  desktop. 
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APPENDIX  B.  REDHAT  LINUX  5.0  CONFIGURATION 


Linux  is  one  of  several  Operating  Systems  supported  by  SeaNet.  The  SCN 
software,  however,  is  designed  specifically  for  Linux  (particularly  the  Red  Hat  version). 
Linux  is  a  freely  distributed  PC-based  UNIX  clone  developed  by  Linus  Torvalds  in  1991 
at  the  University  of  Helsinki,  Finland  [Ref  19].  Linux  is  a  complete  multitasking;  multi¬ 
user  operating  system  that  was  designed  to  maximize  the  capabilities  of  Intel  based 
computer  architecture[Ref  19].  Some  advantages  of  the  Linux  operating  system  are  as 
follows: 

-■  Freely  distributed. 

-  UNIX  features. 

-  32  bit.  Multi-user,  and  Multi-tasking. 

-  Well  documented. 

Compatible  with  Windows,  MS-DOS,  UNIX. 

-  Compact. 

This  remainder  of  this  appendix  will  discuss  how  to; 

1 .  Configure  a  Point-To-Point  (PPP)  interface  using  Red  Hat  Linux  5.0  to  allow 
Point-to-Point  connections  with  an  ISP. 

2.  Configure  Red  Hat  Linux  5.0  to  access  the  Internet  through  a  PPP  interface. 

3.  Turn  specific  interfaces  on/off  using  the  “Usenet”  program. 

4.  Retrieve  a  dynamically  assigned  IP  from  an  ISP  using  the  nestat  command. 

5.  Start  an  Apache  HTTP  server. 

6.  Running  the  SeaNet  Coimmmication  Node  (SCN)  software 
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1 .  Configuring  a  point-to-point  (PPP)  interface. 

-  LEFT  CLICK  the  Modem  button  (shown  below)  firom  the  “Control-panel”. 
This  will  open  the  “Configure  Modem”  dialog  box. 
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LEFT  CLICK  on  the  “Device”  that  corresponds  to  the  COM  port  where  the 
KVH  TU  is  connected.  This  will  HIGHLIGHT  the  “Device”  and  its 
“Information”. 

LEFT  CLICK  the  “OK”  button  when  finished.  This  will  close  the  “Configure 
Modem”  dialog  box. 


LEFT  CLICK  the  Network”  button  (shown  below)  icon  from  the  “Control- 
panel”.  This  will  open  the  “Network  Configurator-Names”  dialog  box. 


LEFT  CLICK  the  “Interfaces”  button  to  open  the  “Network  Configurator- 
Interfaces”  dialog  box. 

-  This  dialog  box  displays  the  interfaces  that  exist  on  the  system.  For  the 

example  below  there  is  a  default  loopback  interface  (lo)  that  cannot  be  altered. 
There  is  1  Ethernet  interface  (ethO),  and  1  PPP  interface  (pppO). 
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LEFT  CLICK  the  “PPP”  (Point-To-Point)  check  box 


LEFT  CLICK  the  “OK”  button.  This  will  open  the  “Create  PPP  Interface” 
dialog  box. 


The  “Device:  ppp2”  represents  the  third  PPP  interface  for  the  example  below. 
The  interfaces  are  labeled  as  “pppX”  where  “X”  is  the  number  of  the  interface 
beginning  at  0.  The  first  interface  would  be  “pppO”,  the  second  “pppl”,  the 
third  “ppp2”,  etc. 

Enter  the  information  specific  to  your  connection  i.e.,  Phone  Number,  login 
name,  and  password.  If  your  ISP  uses  PAP  (Password  Authentication 
Protocol). 

LEFT  CLICK  the  “Use  PAP  authentication”  check  box.  If  your  not  sure 
leave  it  blank  and  ask  your  ISP,  you  can  change  the  setting  later  if  needed. 


LEFT  CLICK  the  “Customize”  button  if  further  customization  is  required  (i.e., 
UNIX  shell  login).  This  will  open  the  “Edit  PPP  Interface-Hardware”  dialog 
box. 
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Match  the  settings  as  shown  below. 

LEFT  CLICK  the  “Use  Hardware  flow  control  and  modem  lines”  check  box. 

LEFT  CLICK  the  “Abort  connection  on  well  known  errors”  check  box. 

LEFT  CLICK  die  “Allow  any  user  to  (de)activate  interface”  check  box. 

LEFT  CLICK  the  drop  down  box  arrow  for  “Line  speed:”  and  SELECT  4800 
from  the  choices 

VERIFY  that  the  “Modem  Port:”  field  is  as  shown  below  “/dev/modem”. 
This  is  the  default  setting  and  it  should  not  be  altered. 


Hilliliii 


vn  vr.ilww  ti-uiitrw  fUiu.tiiuuBlll  Uiltss  • 

"j  E^ca)ie  contrtil  char^^  .  .  i . ' 


H  /yiprt  collection  on  well-loriown 


. 


PPP;t|p^6p; 


11 

m 

00 ; 

1'. 

m 

'tnppi 

:  I?/ 


COcel 


LEFT  CLICK  the  “Communication”  button  when  finished.  This  will  open  the 
“Edit  PPP  Interface-Commimication”  dialog  box 


110 


-  The  “Edit  PPP  Interface-Commimication”  dialog  box  allows  you  to  add  chat 
scripting  to  customize  a  connection.  This  is  useful  when  logging  into  a  Unix 
shell  where  more  information  than  just  name  and  password  are  needed.  Enter 
the  information  specific  to  your  connection. 


-  LEFT  CLICK  the  “Networking”  button  to  open  the  “Edit  PPP  Interface- 
Networldng“  dialog  box. 
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LEFT  CLICK  the  “Set  default  route. . checkbox 


LEFT  CLICK  the  “Restart  PPP  when  connection  fails”  checkbox. 
-  Enter  any  other  information  pertinent  to  your  connection. 


LEFT  CLICK  the  “PAP”  button  to  open  the  “Edit  PPP  Interface-PAP”  dialog 
box. 
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-  The  “Edit  PPP  Interface-PAP”  dialog  box  allows  you  to  enter  information 
specific  to  your  connection  to  use  PAP. 

-  LEFT  CLICK  the  “Done”  button  when  finished. 


LEFT  CLICK  the  Save”  button  to  complete  the  PPP  configuration  and  close 
the  “Edit  PPP  Interface”  dialog  box. 
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2.  Configure  Red  Hat  Linux  5.0  to  access  the  Internet  using  a  point-to-point 
interface. 

-  LEFT  CLICK  the  “Network”  button  to  open  the  “Network  Configurator- 
Names”  dialog  box. 


-  Enter  information  specific  to  your  network  for  “Hostname:”,  “Domain:”,  and 
“Nameservers:”. 


-  LEFT  CLICK  the  “Hosts”  button  to  open  the  “Network  Configurator-Hosts” 
dialog  box. 
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-  VERIFY  that  your  IP  and  hostname  are  listed.  The  127.0.0. 1  is  a  required 
default  tiiat  cannot  be  altered. 


LEFT  CLICK  the  “Interfaces”  button  to  open  the  “Network  Configurator- 
Interfaces”  dialog  box. 
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VERIFY  that  the  required  interfaces  are  present.  This  is  the  same  dialog  box 
that  was  referenced  in  the  previous  section  for  customizing  a  PPP  . 


-  To  VERIFY  the  settings  on  a  particular  interface,  LEFT  CLICK  on  that 
interface  and  LEFT  CLICK  the  “Edit”  button.  This  will  open  up  the 
individual  interface  dialog  box  so  the  settings  can  be  changed. 


-  LEFT  CLICK  the  “Routing”  button  to  open  the  “Network  Configurator- 
Routing”  dialog  box. 
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Enter  the  information  specific  for  your  network.  For  a  PPP  connection  the 
“Default  Gateway  Device:”  must  be  one  of  the  “pppX”  interfaces  created 
earlier.  The  “pppO”  interface  represents  the  ISP  at  NPS.  “pppl”  represents  a 
commercial  ISP  in  the  local  area  near  NPS.  For  a  LAN  connection  both  the 
“Default  Gateway:”  and  the  “Default  Gateway  Device:”  must  be  included. 
For  example  the  NPS  SeaNet  lab  would  need  use  the  settings  listed  below 

Default  Gateway:  1 3 1 . 1 20.63 . 1 

Default  Gateway  Device:  ethO  (the  NIC  for  this  computer) 

LEFT  CLICK  “Save”  when  finished. 


LEFT  CLICK  “Quit”  to  close  the  “Network  Configurator”  dialog  box. 


3.  Turn  specific  interfaces  on/off  using  the  “Usemet”  program. 

-  LEFT  CLICK  on  any  open  spot  on  the  desktop  or  on  the  “Start”  button.  This 
will  open  the  “Start”  menu. 

-  HIGHLIGHT  “Programs”  to  expand  the  “Programs”  submemu. 

-  HIGHLIGHT  “Networking”  to  expand  the  “Neworking”  submenu 
LEFT  CLICK  “Usemet”  to  open  the  “Usemet”  program  shown  below. 


The  Usemet  program  is  a  simple  utility  that  allows  a  user  to  toggle  a  particular  interface 
on/off  with  a  button  named  after  the  interface.  The  “Status  info”  provides  a  color-coded 
indication  whether  an  interface  is  active,  inactive,  or  in  transition.  Here  we  see  that  the 
LAN  connection  “ethO”  has  a  GREEN  status  indication  and  is  thus  active.  The  “pppO” 
and  “pppl”  have  RED  status  indications  to  show  they  inactive.  The  third  color  is 
YELLOW  to  indicate  that  an  interface  is  in  transition.  After  LEFT  CLICKING  on  a 
“pppX”  interface  button  there  will  be  a  YELLOW  status  indication  as  it  dials  and 
connects.  The  status  of  the  interface  will  turn  GREEN  when  a  successful  connection  with 
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the  ISP  has  been  established. 

-  LEFT  CLICK  on  the  desired  “pppX”  “Toggle  Interface”  button  to  initiate  the 
Point-to  Point  connection.  As  discussed  earlier  the  status  will  remain 
YELLOW  until  successfully  connected  when  it  will  turn  GREEN  as  displayed 
below. 

-  LEFT  CLICK  on  the  desired  “pppX”  “Toggle  Interface”  button  to  terminate 
the  connection. 
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4.  Retrieve  a  dynamically  assigned  IP  from  an  ISP  using  the  NESTAT  command 

To  retrieve  a  IP  address  that  was  dynamically  assigned  from  your  ISP,  use  the 
NETSTAT  command 

TYPE  “netstat  -m”  from  a  “Root_Window”.  From  the  example  below,  we 
can  see  that  for  the  “pppO”  interface  the  IP  address  is  “131.120.50  .12”. 


^  Root_Vflndow 

CrootmSl  ■■']#  netstat  -rn 
Kernel  IP  rcmting  table 


i^l  Destination 
i  131.120,50.12 
1 131.120.63.0 
If  127.0.0.0 

lo.o.o.o 

il[root@131  ~]#  I 


Gateway 

O.O.O.O 

O.O.O.O 

O.O.O.O 

131.120.63.1 


Gemask  Flags 

255.255.255.255  UH 

255.255.255.0  U 

255.0.0.0  IJ 

O.O.O.O  IJG 


MSS  Window 
1500  0 
1500  0 
3584  0 
1500  0 


irtt  I face 
0  pppO 
0  ethO 
0  lo 
0  ethO 
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5.  Launching  the  Apache  HTTP  Server 

The  Apache  HTTP  server  must  be  configured  on  the  system  before  it  can  be  used. 
That  configuration  is  beyond  the  scope  of  this  document  but  can  be  found  at 
http://www.apache.org.  Once  configured  it  can  be  launched  using  the  following 
command  from  a  “Root_Window.”  This  means  using  a  terminal  as  the  root  user.  Root 
indicates  superuser  privileges  and  should  be  used  with  caution. 

-  LEFT  CLICK  on  any  open  spot  on  the  desktop  or  on  the  “Start”  button.  This 
will  open  the  “Start”  menu. 

-  HIGHLIGHT  “System  Utilities”  to  expand  the  “System  Utilities”  submenu. 

-  LEFT  CLICK  “Root  Shell”  to  open  the  “Root_Window”  terminal. 

-  TYPE  in  “/usr/local/apache/sbin/apachectl  start”  exactly  as  listed. 

-  PRESS  ENTER.  There  will  be  a  response  “/usr/local/apache/sbin/apachectl 
start:  httpd  started”  as  displayed  indicating  that  the  command  was  successful. 


Root  V/indow 


[rciotei31  •'■]# 

[roi:.t@131  ’U# 

[ rootylSl  "] #  .••■'usr  / local /apache.'''sb i n/apachect  1  start 
.••'’ustV'local/apache.'’'sbiri/apachec:tl  start i  httpd  started 
[rooteiSl  "]#  I 
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6.  Running  the  SeaNet  Communication  Node  Software 
This  section  will  discuss  using  the  SeaNet  Communications  Node  Software  and 
give  a  brief  overview  of  its  functionality.  As  mentioned  earlier  in  the  thesis  the  SeaNet 
Communications  Node  Software  is  a  web  browser  based  program  that  performs  a  variety 
of  administrative  tasks. 

-  LEFT  CLICK  on  any  open  spot  on  the  desktop  or  on  the  “Start”  button.  This 
will  open  the  “Start”  menu. 

HIGHLIGHT  “Applications”  to  expand  the  “Applications”  sub-menu. 

LEFT  CLICK  “Netscape  Navigator”  to  open  the  Netscape  Navigator  program. 
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-  TYPE  “Http://131.120.63.227/SeaNet/SCN”  into  the  address  window.  NOTE 
Substitute  your  own  IP  in  the  line  above. 


-  PRESS  ENTER  when  finished.  This  will  open  the  SeaNet  Communications 
Node  Software  main  screen  as  shown. 
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LEFT  CLICK  the  “Comm  Links”  hyperlink  from  the  menu  box  in  the  top  left 
frame.  This  will  open  the  “Link  Status”  frame  that  is  pictured  below.  This 
table  provide  valuable  information  on  the  status  of  communication  links. 


-  LEFT  CLICK  the  “Accounting”  hyperlink  to  open  the  “Accounting”  frame. 


APPENDIX  C.  LINUX  SNMP  CONFIGURATION  FILE  (SNMPD.CONF) 


This  appendix  is  a  copy  of  die  “snmpd.conf  ’  file.  This  is  the  configuration  file  for 


the  SNMP  agent  that  comes  with  Red  Hat  Linux  5.0.  This  file  is  located  in  the  “/etc/” 


directory. 


# 

#  snmpd.conf  -  created  Thu  Jul  24  22:12:50  MET  DST  1997 

# 

# 

#  view  configuration 

# 

#  viewName  OID  included/excluded 

# 

#  Red  Hat  Special  Define  for  Limited  Access. 

view  rest  .1.3. 6. 1.2. 1.1. 4  included 

#  internet 

view  ail  .1.3. 6.1  included 

#  internet 

view  mini  . 1 . 3 . 6 . 1  included 

#  for  vl  public  exclude  exclude  mib-2 .ident . identinfo 

#  and  mib-2  .host .hr SWRun  in  the  mini  view: 

view  xmini  . 1 . 3 . 6 . 1  included 

view  xmini  .1.3.6.1.2.1.24.1  excluded 

view  xmini  .1.3.6.1.2.1.25.4  excluded 

#  system,  snmp,  usecAgent,  usecStats 

view  semi  .1.3. 6. 1.2. 1.1 

view  semi  .1.3.6.1.2.1.11 

view  semi  .1.3. 6. 1.6. 3. 6. 1.1 

view  semi  .1.3. 6. 1.6. 3. 6. 1.2 

#  snmp,  usecAgent,  usecStats 

view  semi  .1.3.6.1.2.1.11  included 

view  semi  .1.3. 6. 1.6. 3. 6. 1.1  included 

view  semi  .1.3. 6. 1.6. 3. 6. 1.2  included 


# 

# 

#  user  configuration 

# 

#  noneRV  noneWV  authRV  authWV  userName [/authKey] 

# 

#  If  you  uncomment  the  following  line: 

#  -  make  sure  you  understand  what  giving  write  access  means 

#  -  use  authkey(l)  to  generate  a  new  hex  authkey 

# 

#user  mini  -  all  all  public/PUT_^UTH_KEY_HERE 


# 

# 

#  community  configuration 

# 

#  commName  readV  writeV 

# 

community  public  rest 

##  uncomment  for  private  entry: 


included 

included 

included 

included 
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#  community  private  mini  mini 


## 

##  now  follows  the  specific  section  of  the  linux~port, 
## 


## 

##  port  to  use  (default  is  161) : 

## 

#  port:  161 

## 

##  the  entry  of  system. Contact  and  system. Location: 

## 

sysContact:  Please  configure  your  snmpd  before  running. 

sysLocation:  Not  Configured 

##  the  system  name  is  per  default  determined  from  the  hostname: 

#  sysName :  Chappell 

## 

##  trap  sink  address  and  community  string,  (passed  to  snmptrap(l) 

##  utility) .  authentraps  contains  the  value  of  snmpEnableAuthenTraps 
##  (default  is  'disabled*). 

## 

trap  sink:  localhost 

trap  community:  public 

snmpEnableAuthenTraps :  disabled 

## 

##  specify  type  and  speed  of  interfaces: 

##  if  the  last  char  is  an  asterisk,  any  suffix  will  match. 

##  (feel  free  to  add  more) 

## 


interface : 

loO 

24 

20000000 

interface : 

eth* 

6 

10000000 

interface : 

si* 

28 

28800 

interface: 

ppp* 

23 

28800 

interface: 

isdn* 

20 

64000 

interface: 

ippp* 

20 

64000 

##  end  of 

/etc/snmpd. 

.conf 
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APPENDIX  D.  LINUX-SUPPORTED  MIB  VARIABLES 


The  following  list  contains  all  the  MIB-II  variables  supported  by  Red  Hat  Linux 
5.0.  This  list  was  generated  by  SNMP  polling  of  the  NPS  shipboard  computer  with  the 
HPOV  NMS.  MBB-n  object  descriptions  corresponding  to  the  numbers  can  be  fovmd  in 


RFC  1156  and  RFC  1213. 


Name  or  IP  Address;  131.120.63.227 
Community  Name: 

MIB  Object  ID:  .iso. org. dod. interne t .mgmt 
MIB  Instance; 

SNMP  Set  Value: 


MIB  Values 

1.1. 1. 

Nov  19  00: 

1.1.2. 

1.1.3. 

1.1.4. 

1.1.5. 

1.1.6. 

1.1.7. 

1.1.8. 
1.1.9. 
1.1.9. 
1.1.9. 
1.2.1. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 
1.2.2. 


:  Linux  version  2.0.32  (rooteporky.redhat . com)  (gcc  version  2. 7. 2. 3)  #1  Wed 
:45  EST  1997 

;  . iso . org . dod . internet . private . enterprises . 157  5.1.5 
:  (10238)  0:01:42.38 
:  Christopher  L.  Pratt 
:  131.120.63.227 
:  Root  Hall  Room  222 
:  72 

:  (10244)  0:01:42.44 


1 
1 
1 
2 
1.1 
1.2 
2.1 


4.2 

5.1 

5.2 

6.1 

6.2 

7.1 


.iso. org. dod. internet. private. enterprises . 1575.1.5.1.1 
LINUX  agent 
(10248)  0:01:42.48 

1 

2 

loO 

ethO 

24 

6 

3584 

1500 

20000000 

10000000 


7.2 

8.1 

8.2 

9.1  ; 

9.2  : 

10.1  ; 

10.2  ; 
11.1  : 
11.2  : 
12.1  : 
12.2  : 

13.1  : 

13.2  : 

14.1  : 

14.2  : 

15.1  : 

15.2  : 


0:00: 

0:00: 


00  00 
00  CO 
1 
1 
1 
1 

(0) 

(0) 

616 

281204 

2 

915 

0 

0 

0 

0 

0 

0 

0 

0 


00  00  00  00 
4F  86  5D  D7 


00.00 

00.00 
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1.2.2.1.16.1  :  616 

1.2.2.1.16.2  :  189728 

1.2.2.1.17.1  :  2 

1.2.2.1.17.2  :  618 

1.2.2.1.18,1  :  0 

1.2.2.1.18.2  :  0 

1.2.2.1.19.1  :  0 

1.2.2.1.19.2  :  0 

1.2.2.1.20.1  :  0 

1.2.2.1.20.2  :  0 

1.2.2.1.21.1  :  0 

1.2.2.1.21.2  :  0 

1.2.2.1.22.1  ;  . iso. org.dod. internet. mgmt. 1.2. 2. 1.22. 0.0 

1.2.2.1.22.2  :  .iso.org.dod. internet .mgmt . 1 .2 . 2 . 1 .22 . 0 . 0 

1.3.1.1.1.2.1.131.120.63.226  :  2 

1.3.1.1.2.2.1.131.120.63.226  ;  08  00  09  48  1C  FF 

1.3.1.1.3.2.1.131.120.63.226  :  131.120.63.226 
1.4. 1.0  :  2 

1.4.2.0  :  64 
1.4. 3.0  :  718 
1.4. 4.0  :  0 
1.4. 5.0  :  0 
1.4. 6.0  :  0 
1.4. 7.0  :  0 
1.4. 8.0  :  0 
1.4. 9.0  :  684 
1.4.10.0  :  642 
1.4.U.0  :  0 
1.4.12.0  :  0 
1.4.13.0  :  0 
1.4.14.0  :  0 
1.4.15.0  :  0 
1.4.16.0  :  0 
1.4.17.0  :  0 
1.4.18.0  :  0 
1.4.19.0  :  0 

1.4.20.1.1.127.0.0.1  :  127.0.0.1 

1.4.20.1.1.131.120.63.227  :  131.120.63.227 
1.4.20.1.2.127.0.0.1  :  1 

1.4.20.1.2.131.120.63.227  :  2 
1.4.20.1.3.127.0.0.1  :  255.0.0.0 

1.4.20.1.3.131.120.63.227  :  255.255.255,0 
1.4.20.1.4.127.0.0.1  :  1 

1.4.20.1.4.131.120.63.227  :  1 
1.4.20.1.5.127.0.0.1  :  20480 

1.4.20.1.5.131.120.63.227  :  20480 
1.4.21.1.1.0.0.0.0  :  0.0. 0.0 
1.4.21.1.1.127.0.0.0  :  127.0.0.0 
1.4.21.1.1.131.120.63.0  ;  131.120.63.0 
1.4.21.1.2.0.0.0.0  :  2 
1.4.21.1.2.127.0.0.0  :  1 
1.4.21.1.2.131.120.63.0  :  2 
1.4.21.1.3.0.0.0.0  :  1 
1.4.21.1.3.127.0.0.0  ;  0 
1.4.21.1.3.131.120.63.0  :  0 
1.4.21.1.4.0.0.0.0  :  -1 
1.4.21.1.4.127.0.0.0  :  -1 
1.4.21.1.4.131.120.63.0  :  -1 
1.4.21.1.5.0.0.0.0  :  -1 
1.4.21.1.5.127.0.0.0  :  -1 
1.4.21.1.5.131.120.63.0  :  -1 
1.4.21.1.6.0.0.0.0  :  -1 
1.4.21.1.6.127.0.0.0  :  ~1 
1.4.21.1.6.131.120.63.0  :  -1 
1.4.21.1.7.0.0.0.0  :  131.120.63.1 
1.4.21.1.7.127.0.0.0  :  0.0. 0.0 
1.4.21.1.7.131.120.63.0  :  0.0. 0.0 
1.4.21.1.8.0.0.0.0  :  4 
1.4.21.1.8.127.0.0.0  :  3 
1.4.21.1.8.131.120.63.0  :  3 
1.4.21.1.9.0.0.0.0  :  2 
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1. 

1, 

1. 

1. 

1, 

1. 

1. 

1. 

1. 

1, 

1. 

1, 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 

1. 


21.1.9.127.0.0.0  :  2 
21.1.9.131.120.63.0  :  2 
21.1.10.0.0.0.0  :  0 
.10.127.0.0.0  :  0 
.10.131.120.63.0  :  0 
.11.0.0.0.0  :  0.0. 0.0 
.11.127.0.0.0  :  255.0.0.0 
.11.131.120.63.0  :  255.255.255.0 
.12.0.0.0.0  :  -1 
.12.127.0.0.0  :  -1 
.12.131.120.63.0  :  -1 
.1.2.131.120.63.226  :  2 
.2.2.131.120.63.226  :  08  00  09  48  7C  FF 
.3.2.131.120.63.226  :  131.120.63.226 
.4.2.131.120.63.226  ;  3 
:  6 
:  0 
:  1 
:  0 
:  0 
;  0 
:  0 
:  5 
:  0 
:  0 
:  0 
:  0 
:  0 
:  6 
:  0 
:  1 
:  0 
:  0 
:  0 
:  0 
:  0 
:  5 
:  0 
:  0 
:  0 
:  0 
1 
0 
0 
0 
0 
0 
0 
0 
0 

:  0 
:  0 
:  0 

.1.0.0.0.0.21.0.0.0.0.0  :  2 
.1.0.0.0.0.22.0.0.0.0.0  :  2 
.1.0.0.0.0.23.0.0.0.0.0  :  2 
.1.0.0.0.0.111.0.0.0.0.0  :  2 
.1.0.0.0.0.139.0.0.0.0.0  :  2 
.1.0.0.0.0.515.0.0.0.0.0  :  2 
.1.0.0.0.0.5432.0.0.0.0.0  :  2 
.2.0.0.0.0.21.0.0.0.0.0  :  0.0. 0.0 
.2.0.0.0.0.22.0.0.0.0.0  :  0.0. 0.0 
.2.0.0.0.0.23.0.0.0.0.0  :  0.0. 0.0 
,2.0.0.0.0.111.0.0.0.0.0  ;  0. 0.0.0 
2.0.0.0.0.139.0.0.0.0.0  :  0. 0.0.0 
2.0.0.0.0.515.0.0.0.0.0  :  0.0. 0.0 
2.0.0.0.0.5432.0.0.0.0.0  :  0.0. 0.0 
3.0.0.0.0.21.0.0.0.0.0  :  21 
3.0.0.0.0.22.0.0.0.0.0  :  22 
3.0.0.0.0.23.0.0.0.0.0  ;  23 
3.0.0.0.0.111.0.0.0.0.0  :  111 


.21 
.21 
.21 
.21 
.21 
.21 
.21 
.21 
.22 
.22 
,22.1 
,22.1 
,1.0 
,2.0 
,3.0 
.4.0 
,5.0 
6.0 
7.0 
8.0 
9.0 
10.0 
11.0 
12.0 
13.0 
14.0 
15.0 
16.0 
17,0 
18.0 
19.0 
20.0 
21.0 
22.0 
23.0 
24.0 
25.0 
26.0 
1.0 
2.0 
3.0 
4.0 
5.0 
6.0 
7.0 
8.0 
9,0 
10.0 
11.0 
12.0 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
13.1. 
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1.6.13.1.3.0.0.0.0.139.0.0.0.0. 

1.6.13.1.3.0.0.0.0.515.0.0.0.0. 

1.6.13.1.3.0.0.0.0.5432.0.0.0.0 

1.6.13.1.4.0.0.0.0.21.0.0.0.0.0 

1.6.13.1.4.0.0.0.0.22.0.0.0.0.0 

1.6.13.1.4.0.0.0.0.23.0.0.0.0.0 

1.6.13.1.4.0.0.0.0.111.0.0.0.0. 

1.6.13.1.4.0.0.0.0.139.0.0.0.0. 

1.6.13.1.4.0.0.0.0.515.0.0.0.0. 

1.6.13.1.4.0.0.0.0.5432.0.0.0.0 

1.6.13.1.5.0.0.0.0.21.0.0.0.0.0 

1.6.13.1.5.0.0.0.0.22.0.0.0.0.0 

1.6.13.1.5.0.0.0.0.23.0.0.0.0.0 

1.6.13.1.5.0.0.0.0.111.0.0.0.0. 

1.6.13.1.5.0.0.0.0.139.0.0.0.0. 

1.6.13.1.5.0.0.0.0.515.0.0.0.0. 

1.6.13.1.5.0.0.0.0.5432.0.0.0.0 

1.7. 1.0  :  769 

1.7. 2.0  :  1 

1.7. 3.0  :  0 

1.7. 4.0  :  772 

1.7.5.1.1.0.0.0.0.111  :  0.0. 0.0 
1.7.5.1.1.0.0.0.0.161  :  0.0. 0.0 
1.7.5.1.1.0.0.0.0.514  :  0.0. 0.0 
1.7.5.1.2.0.0.0.0.111  :  111 
1.7.5.1.2.0.0.0.0.161  :  161 
1.7.5.1.2.0.0.0.0.514  :  514 
1.11.1.0  :  779 
1.11.2.0  :  779 
1.11.3.0  :  0 
1.11.4.0  :  0 
1.11.5.0  :  0 
1.11.6.0  :  0 
1.11.8.0  :  0 
1.11.9.0  ;  0 
1.11.10.0  :  0 
1.11.11.0  :  0 
1.11.12.0  :  0 
1.11.13.0  :  790 
1.11.14.0  :  0 
1.11.15.0  :  8 
1.11.16.0  :  785 
1.11.17.0  ;  0 
1.11.18.0  :  0 
1.11.19.0  :  0 
1.11.20.0  :  0 
1.11.21.0  :  0 
1.11.22.0  :  0 
1.11.24.0  :  0 
1.11.25.0  :  0 
1.11.26.0  :  0 
1.11.27.0  :  0 
1.11.28.0  ;  0 
1.11.29.0  :  0 
1.11.30.0  :  1 

1.24.1.1.1.1.0.0.0.0.21.0.0.0.0. 
1.24.1.1.1.1.0.0.0.0.22.0.0.0.0, 
1.24.1.1.1.1.0.0.0.0.23.0.0.0.0, 
1. 24. 1. 1.1. 1.0. 0.0.0. 111. O.O.O.C 
1. 24. 1. 1.1. 1.0. 0.0.0. 139. O.O.O.C 
1.24. 1.1. 1.1. 0.0. 0.0. 515. O.O.O.C 
1.24.1.1.1.1.0.0.0.0.5432.0.0.0. 
1.24.1.1.1.2.0.0.0.0.21.0.0.0.0. 
1.24.1.1.1.2.0.0.0.0.22.0.0.0.0. 
1.24.1.1.1.2.0.0.0.0.23.0.0.0.0, 
1.24. 1.1. 1.2. 0.0. 0.0. 111. O.O.O.C 
1.24. 1.1. 1.2. 0.0. 0.0. 139. O.O.O.C 
1.24. 1.1. 1.2. 0.0. 0.0. 515. O.O.O.C 
1.24.1.1.1.2.0.0.0.0.5432.0.0.0. 
1.24.1.1.1.3.0.0.0.0.21.0.0.0.0, 
1.24.1.1.1.3.0.0.0.0.22.0.0.0.0. 


0  :  139 
0  :  515 
.0  :  5432 
:  0.0. 0.0 
:  0.0. 0.0 
:  0.0. 0.0 
0  :  0.0. 0.0 
0  :  0.0. 0.0 
0  :  0.0. 0.0 
.0  :  0.0.0. 0 
:  0 
:  0 
:  0 
0  :  0 
0:0 
0  :  0 
.0  :  0 


0  :  1 
0  :  1 
0  :  1 
1.0  :  1 
1.0  :  1 
1.0  :  1 
0.0  :  1 
0  :  Unix 
0  :  Unix 
0  :  Unix 
1.0  :  Unix 
1.0  :  Unix 
.0  :  Unix 
0.0  :  Unix 
0  :  US-ASCII 
0  ;  US-ASCII 
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1.24.1.1.1.3.0.0.0.0.23.0.0.0.0.0  :  US-ASCII 
1.24.1.1.1.3.0.0.0.0.111.0.0.0.0.0  :  US-ASCII 
1.24.1.1.1.3.0.0.0.0.139.0.0.0.0.0  :  US-ASCII 
1.24.1.1.1.3.0.0.0.0.515.0.0.0.0.0  :  US-ASCII 
1.24.1.1.1.3.0.0.0.0.5432.0.0.0.0.0  :  US-ASCII 
1.24. 1.1. 1.4. 0.0. 0.0.21.0,0.0.0.0  :  root 
1.24.1.1.1.4.0.0.0.0.22.0.0.0.0.0  :  root 
1.24.1.1.1.4.0.0.0.0.23.0.0.0.0.0  :  root 
1.24.1.1.1.4.0.0.0.0.111.0.0.0.0.0  :  root 
1.24.1.1.1.4.0.0.0.0.139.0.0.0.0.0  :  root 
1.24.1.1.1.4.0.0.0.0.515.0.0.0.0.0  :  root 
1.24.1.1.1.4.0.0.0.0.5432.0.0.0.0.0  :  postgres 
1.24.1.1.1.5.0.0.0.0.21.0.0.0.0.0  :  root,,,, 
1.24.1.1.1.5.0.0.0.0.22.0.0.0.0.0  :  root,,,, 
1.24.1.1.1.5.0.0.0.0.23.0.0.0.0.0  :  root,,,, 
1.24.1.1.1.5.0.0.0.0.111.0.0.0.0.0  :  root,,,, 
1.24.1.1.1.5.0.0.0.0.139.0.0.0.0.0  :  root,,,, 
1.24.1.1.1.5.0.0.0.0.515.0.0.0.0.0  :  root,,,, 
1.24.1.1.1.5.0.0.0.0.5432.0.0.0.0.0  :  PostreSQL  Server 
1.25.1.1.0  :  (12446)  0:02:04.46 
1.25.1.2.0  :  00  62  08  IB  OD  2B  lE  00 
1.25.1.3.0  :  774 

1.25.1.4.0  :  auto  BOOT_IMAGE=linux  ro  root=306 

1.25.1.5.0  :  2 

1.25.1.6.0  :  24 

1.25.1.7.0  :  512 

1.25.2.2.0  :  65536 

1.25..2.3.1.1.1  :  1 

1.25.2.3.1.1.2  :  2 

1.25.2.3.1.1.774  :  774 

1.25.2.3.1.2.1  :  . iso. org.dod. internet. mgmt. 1.25.2.1.2 

1.25.2.3.1.2.2  :  .iso. org.dod. internet. mgmt. 1.25. 2. 1.3 

1.25.2.3.1.2.774  :  .iso .org.dod. internet .mgmt . 1 .25 .2 . 1 . 4 

1.25.2.3.1.3.1  :  Mem 

1.25.2.3.1.3.2  :  Swap 

1.25.2.3.1.3.774  :  Disk 

1.25.2.3.1.4.1  :  1024 

1.25.2.3.1.4.2  :  1024 

1.25.2.3.1.4.774  :  1024 

1.25.2.3.1.5.1  :  63160 

1.25.2.3.1.5.2  :  64224 

1.25.2.3.1.5.774  ;  987220 

1.25.2.3.1.6.1  :  11780 

1.25.2.3.1.6.2  :  0 

1.25.2.3.1.6.774  :  760413 

1.25.2.3.1.7.1  ;  0 

1.25.2.3.1.7.2  :  0 

1.25.2.3.1.7.774  :  0 

1.25.3.2.1.1.1  :  1 

1.25.3.2.1.2.1  :  .iso. org.dod. internet. mgmt. 1.25. 3. 1.3 

1.25.3.2.1.3.1  :  processor:  0,  cpu:  686 

1.25.3.2.1.4.1  :  .ccitt.O 

1.25.3.2.1.5.1  :  2 

1.25.3.2.1.6.1  :  0 

1.25.3.3.1.1.1  :  .ccitt.O 

1.25.3.3.1.2.1  :  0 

1.25.3.8.1.1.774  :  774 

1.25.3.8.1.2.774  :  /dev/hda6 

1.25.3.8.1.3.774  :  / 

1.25.3.8.1.4.774  :  .iso.org.dod.internet .mgmt. 1.25.3. 9.2 

1.25.3.8.1.5.774  :  1 

1.25.3.8.1.6.774  :  1 

1.25.3.8.1.7.774  :  774 

1.25.3.8.1.8.774  :  00  00  01  01  00  00  00  00 

1.25.3.8.1.9.774  :  00  00  01  01  00  00  00  00 
1.25.4.1.0  :  1 

1.25.4.2.1.1.0  :  0 

1.25.4.2.1.1.1  :  1 

1.25.4.2.1.1.2  :  2 

1.25.4.2.1.1.3  :  3 
1.25.4.2.1.1.23  :  23 
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1.25.4.2.1.1.180 

1.25.4.2.1.1.189 

1.25.4.2.1.1.200 

1.25.4.2.1.1.211 

1.25.4.2.1.1.222 

1.25.4.2.1.1.233 

1.25.4.2.1.1.246 

1.25.4.2.1.1.257 
1.25.4.2.K1.268 

1.25.4.2.1.1.283 

1.25.4.2.1.1.288 

1.25.4.2.1.1.304 

1.25.4.2.1.1.326 

1.25.4.2.1.1.327 

1.25.4.2.1.1.328 

1.25.4.2.1.1.329 

1.25.4.2.1.1.330 

1.25.4.2.1.1.331 

1.25.4.2.1.1.333 

1.25.4.2.1.1.334 
1.25.4.2.1.2.0  : 

1.25.4.2.1.2.1  : 

1.25.4.2.1.2.2  : 

1.25.4.2.1.2.3  : 

1.25.4.2.1.2.23  : 

1.25.4.2.1.2.180 

1.25.4.2.1.2.189 

1.25.4.2.1.2.200 

1.25.4.2.1.2.211 

1.25.4.2.1.2.222 

1.25.4.2.1.2.233 

1.25.4.2.1.2.246 

1.25.4.2.1.2.257 

1.25.4.2.1.2.268 

1.25.4.2.1.2.283 

1.25.4.2.1.2.288 

1.25.4.2.1.2.304 

1.25.4.2.1.2.326 

1.25.4.2.1.2.327 

1.25.4.2.1.2.328 

1.25.4.2.1.2.329 

1.25.4.2.1.2.330 

1.25.4.2.1.2.331 

1.25.4.2.1.2.333 

1.25.4.2.1.2.334 
1.25.4.2.1.3.0  : 

1.25.4.2.1.3.1  : 

1.25.4.2.1.3.2  : 

1.25.4.2.1.3.3  : 

1.25.4.2.1.3.23  : 

1.25.4.2.1.3.180 

1.25.4.2.1.3.189 

1.25.4.2.1.3.200 

1.25.4.2.1.3.211 

1.25.4.2.1.3.222 

1.25.4.2.1.3.233 

1.25.4.2.1.3.246 

1.25.4.2.1.3.257 

1.25.4.2.1.3.268 

1.25.4.2.1.3.283 

1.25.4.2.1.3.288 

1.25.4.2.1.3.304 

1.25.4.2.1.3.326 

1.25.4.2.1.3.327 

1.25.4.2.1.3.328 

1.25.4.2.1.3.329 

1.25.4.2.1.3.330 

1.25.4.2.1.3.331 

1.25.4.2.1.3.333 

1.25.4.2.1.3.334 
1.25.4.2.1.4.0  : 


:  180 
:  189 
:  200 
:  211 
:  222 
:  233 
:  246 
:  257 
:  268 
:  283 
:  288 
:  304 
:  326 
:  327 
:  328 
:  329 
:  330 
:  331 
:  333 
:  334 
(unknown) 
(unknown) 
(unknown) 
(unknown) 
(unknown) 

;  (unknown) 
:  (unknown) 
:  (unknown) 
;  (unknown) 
:  (unknown) 
:  (unknown) 
:  (unknown) 
:  (unknown) 
:  (unknown)' 
:  ( unknown ) 
:  (unknown) 
:  (unknown) 
:  (unknown) 
;  ( unknown ) 
:  (unknown) 
:  (unknown) 
:  (unknown) 
:  (unknown) 
:  (unknown) 
:  (unknown) 
.ccitt. 0 
.ccitt.O 
.ccitt .0 
.ccitt.O 
. ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
;  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
:  .ccitt.O 
(unknown) 
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1.25.4.2. 

1.25.4.2. 

1.25.4.2. 

1.25.4.2. 

1.25.4.2. 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.2514.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 

1.25.4.2 


1.4.1  :  init 

1.4.2  :  kflushd 

1.4.3  :  kswapd 


1.4.23  : 

kerne Id 

1.4.180 

:  syslogd 

1.4.189 

:  klogd 

1.4.200 

:  atd 

1.4.211 

:  crond 

1.4.222 

:  portmap 

1.4.233 

:  snmpd 

1.4.246 

:  inetd 

1.4.257 

:  sshd 

1.4.268 

:  Ipd 

1.4.283 

:  gpm 

1.4.288 

:  postmaster 

1.4.304 

;  smbd 

1.4.326 

:  login 

1.4.327 

:  mingetty 

1.4.328 

:  mingetty 

1.4.329 

;  mingetty 

1.4.330 

:  mingetty 

1.4.331 

:  mingetty 

1.4.333 

:  update 

1.4.334 

:  tcsh 

1.5.0  ; 

(unknown) 

1.5.1  : 

init  [3] 

1.5.2  : 

(kflushd) 

1.5.3  : 

(kswapd) 

1.5.23  : 

/sbin/kerneld 

1.5.180 

:  syslogd 

1,5.189 

:  klogd 

1.5.200 

:  /usr/sbin/atd 

1.5.211 

:  crond 

1.5.222 

;  portmap 

1.5.233 

:  /usr/sbin/snmpd  -f 

1.5.246 

:  inetd 

1.5.257 

;  /usr/local/sbin/sshd 

1.5.268 

:  Ipd 

1.5.283 

:  gpm  -t  PS/2 

1.5.288 

:  /usr/bin/postmaster  ■ 

1.5.304 

:  smbd  -*D 

1.5.326 

:  /bin/login  —  root 

1.5.327 

:  /sbin/mingetty  tty2 

1.5.328 

:  /sbin/mingetty  tty3 

1.5.329 

:  /sbin/mingetty  tty4 

1.5.330 

:  /sbin/mingetty  tty5 

1.5.331 

:  /sbin/mingetty  tty6 

1.5.333 

:  update  (bdflush) 

1.5.334 

:  -tcsh 

1.6.0  :  4 

1.6.1  :  4 

1.6.2  :  4 

1.6.3  :  4 
1.6.23  :  4 
1.6.180  :  4 
1.6.189  :  4 
1.6.200  :  4 
1.6.211  :  4 
1.6.222  :  4 
1.6.233  :  4 
1.6.246  :  4 
1.6.257  :  4 
1.6.268  :  4 
1.6.283  :  4 
1.6.288  :  4 

.1.6.304  :  4 
1.6.326  :  4 
.1.6.327  :  4 
.1.6.328  :  4 
.1.6.329  :  4 
.1.6.330  :  4 


-D/var/lib/pgsql 
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1.25.4.2.1.6.331  ;  4 

1.25.4.2.1.6.333  :  4 

1.25.4.2.1.6.334  :  4 
1.25.4.2.1.7.0  :  2 

1.25.4.2.1.7.1  :  2 

1.25.4.2.1.7.2  :  2 

1.25.4.2.1.7.3  :  2 
1.25.4.2.1.7.23  :  2 
1.25.4.2.1.7.180  :  2 
1.25.4.2.1.7.189  :  2 
1.25.4.2.1.7.200  :  2 
1.25.4.2.1.7.211  :  2 
1.25.4.2.1.7.222  :  2 
1.25.4.2.1.7.233  :  1 
1.25.4.2.1.7.246  :  2 
1.25.4.2.1.7.257  :  2 
1.25.4.2.1.7.268  :  2 
1.25.4.2.1.7.283  :  2 
1.25.4.2.1.7.288  :  2 
1.25.4.2.1.7.304  :  2 

1.25.4.2.1.7.326  :  2 

1.25.4.2.1.7.327  :  2 

1.25.4.2.1.7.328  :  2 

1.25.4.2.1.7.329  :  2 

1.25.4.2.1.7.330  :  2 

1.25.4.2.1.7.331  :  2 

1.25.4.2.1.7.333  :  2 

1.25.4.2.1.7.334  :  2 
1.25:5.1.1.1.0  :  0 
1.25.5.1.1.1.1  :  337 


1.25.5.1.1.1.2  : 

0 

1.25.5.1.1.1.3  : 

0 

1.25.5.1.1.1.23  : 

1 

1.25.5.1.1.1.180 

7 

1.25.5.1.1.1.189 

11 

1.25.5.1.1.1.200 

1 

1.25.5.1.1.1.211 

1 

1.25.5.1.1.1.222 

1 

1.25.5.1.1.1.233 

36 

1.25.5.1.1.1.246 

1 

1.25.5.1.1.1.257 

107 

1.25.5.1.1.1.268 

0 

1.25.5.1.1.1.283 

0 

1.25.5.1.1.1.288 

0 

1.25.5.1.1.1.304 

0 

1.25.5.1.1.1.326 

10 

1.25.5.1.1.1.327 

1 

1.25.5.1.1.1.328 

0 

1.25.5.1.1.1.329 

0 

1.25.5.1.1.1.330 

1 

1.25.5.1.1.1.331 

1 

1.25.5.1.1.1.333 

1 

1.25.5.1.1.1.334 

11 

1.25.5.1.1.2.0  : 

6 

1.25.5.1.1.2.1  : 

400 

1.25.5.1.1.2.2  : 

0 

1.25.5.1.1.2.3  : 

0 

1.25.5.1.1.2.23  : 

356 

1.25.5.1.1.2.180 

452 

1.25.5.1.1.2.189 

548 

1.25.5.1.1.2.200 

420 

1.25.5.1.1.2.211 

492 

1.25.5.1.1.2.222 

340 

1.25.5.1.1.2.233 

764 

1.25.5.1.1.2.246 

416 

1.25.5.1,1.2.257 

572 

1.25.5.1.1.2.268 

428 

1.25.5.1.1.2.283 

352 

1.25.5.1.1.2.288 

816 

1.25.5.1.1.2.304 

600 

1.25.5.1.1.2.326 

940 
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1.25.5.1.1.2.327  ;  320 

1.25.5.1.1.2.328  :  320 

1.25.5.1.1.2.329  :  320 

1.25.5.1.1.2.330  :  320 

1.25.5.1.1.2.331  :  320 

1.25.5.1.1.2.333  :  244 

1.25.5.1.1.2.334  :  868 
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